Hope you're well Fletcher. I stopped following the list and similar for a number of reasons - like breaking stable behaviour, it being debated in internal scrums (and no one reached back before Valve issued threats!) for no reason. I gave up after defeating the latest regression fully using basic asmjs + remote code exec which is 100% not the avenue that I wanted to utilize + ultimately aging out. SRCDS is not the same reflection avenue that SNMP and some russian STB HTTP protocol had a decade ago - and even now post other games implementing the wire protocol. Arbitrarily it looks like it's 8x right now and you're proposing breaking stable wire for an additional Byte which does not help fix this. The game thread will still get destroyed on responses per usual, and reflection attacks using SRCDS are just not relevant anymore.
I think where I'm going with this is why on gods green earth are we doing this when SRCDS is just not a majority stakeholder on the internet anymore. I'm confuzzled: and now I'm confused. Kyle. On Mon, Nov 16, 2020 at 5:22 PM Fletcher Dunn - fletcherd at valvesoftware.com (via csgo_servers list) <csgo_servers@list.valvesoftware.com> wrote: > > Hello! > > > > Over the next couple of months we will be releasing some changes to how > servers and clients using steamclent.so/dll handle the venerable Source > engine A2S_INFO message used by the server browser. This includes the Steam > client server browser, all Source engine games, and all Steam games using the > ISteamMatchmaking API. The purpose of these changes is a long overdue fix > for a reflection attack vulnerability. > > > > This email is to let you know what those plans are and to solicit your > feedback. Fixing the vulnerability requires changing the protocol and will > necessarily break existing third party utilities that speak the protocol. > > > > Currently, the A2S_INFO packet looks like this: > > 4 bytes: 0xFFFFFFFF > > 1 byte: 0x54 (A2S_INFO packet type identifier) > > 20 bytes: "Source Engine Query\0" > > > > The proposal is for clients to modify the A2S_INFO packet they send in one > of two ways: > > > > Option 1: Pad the message with zeros, so that the request is larger than the > reply. The passes size is TBD, but it will probably be at least 800 bytes, > and perhaps as high as 1200. Feedback is requested concerning this size. > > > > Option 2: Append a 4-byte anti-spoofing challenge obtained using the existing > A2S_PLAYER or A2S_RULES messages. > > > > Note that both options produce a packet that is acceptable to the current > code in steamclient.so/dll. However, any custom handlers might have stricter > behavior, and will need to be updated to be aware than “extra” data might > appear after the end of the magic string in packets from legitimate clients. > > > > Once all clients are using one of these two options, a server wishing to > avoid being vulnerable to reflection attacks could drop any A2S_INFO packets > below a minimum size without a challenge. > > > > The changes would be deployed as follows: > > > > 1.) First, we will release a new Steam client that sends A2S_INFO > messages padding to a minimum size. (Option #1 above.) Since it takes time > for Steam client updates to roll out to all Steam users, and for third > parties to change their code to make queries in the new format, we will not > change the server to require the new format by default. However, the server > code will be updated to look for an environment variable that can be used to > opt into the new, stricter behavior. This is so that third parties can test > their clients to make sure they are compliant with the new server code. > > 2.) As more clients upgrade to the new code and third party tools are > updated to send queries in the new format, server operators may elect to opt > into the new behavior at their discretion using the environment variable. > > 3.) After some time has passed (and we have posted several warnings on > this mailing list), we will ship a new steamclient.so/.dll that has the > strict behavior enabled by default. A different environment variable can be > used to use the older, more permissive behaviour. > > > > If you have any concerns or feedback about this change, please reply to this > steam post: > > https://steamcommunity.com/discussions/forum/14/2989789048633291344/ > > > > After feedback has been collected and details finalized, I’ll post again with > more technical details about the changes that are going to be made. > > _______________________________________________ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > https://list.valvesoftware.com/ _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/
