Ah yes, I see it now. Thank you Marco for that breakdown. On Wed, Nov 18, 2020 at 3:00 AM Marco Padovan <[email protected]> wrote:
> What is being tackled here is the amplification factor > > > https://github.com/Phenomite/AMP-Research/tree/master/Port%2027015%20(%2B%20more%20ports)%20-%20SRCDS%20(Arma3%2C%20Gmod%2C%20CSGO%2C%20etc) > > that means an attacker with a 100mbps connection at hand that allows > spoofing could use srcds servers to achieve a 500mbps reflected attack > towards a target > > big packets means the same attacker with a 100mbps connection would end up > being able to only attack the target with potentially even less mbps then > what he already had access to > > On Wed, 18 Nov 2020 at 04:23, David Parker <[email protected]> wrote: > >> Moving the server side of the query handling to the GMS would solve all >> of the issues for GSPs and others hosting the games. That makes perfect >> sense to me. >> >> However, regarding the increased packet size (option #1), I'm a little >> confused. If the idea here is that the servers expect really big packets >> and reject anything too small, couldn't the asshats who launch these >> attacks just update their existing code to pad the requests with zeros, and >> we're back to the same problem? There's probably a piece to this that I'm >> missing, and I apologize for my ignorance. >> >> Thanks! >> Dave >> >> On Tue, Nov 17, 2020 at 4:53 PM Fletcher Dunn - fletcherd at >> valvesoftware.com (via csgo_servers list) < >> [email protected]> wrote: >> >>> >It depends now on what you're doing with SDR ;-). >>> >>> Yes, there are mechanisms to measure the latency to servers in known >>> data centers, as well as to arbitrary hosts on the Internet using SDR P2P >>> functionality. I was referring to the ordinary servers. >>> >>> -----Original Message----- >>> From: Kyle Sanderson <[email protected]> >>> Sent: Tuesday, November 17, 2020 1:15 PM >>> To: Fletcher Dunn <[email protected]> >>> Cc: [email protected] >>> Subject: Re: [Csgo_servers] RFC: Changes to the A2S_INFO protocol >>> >>> > I think some ping will always be necessary to measure the latency and >>> > confirm UDP connectivity >>> >>> It depends now on what you're doing with SDR ;-). >>> >>> If you're planning on opening this up for optimized PoPs you already >>> have the latency from the client, and the latency from the PoP to the >>> server so you can return the sum there. One of the no-steam guys did this >>> in like 2003 with his browser but he didn't control the PoPs. The latency >>> was still off because he did addition of the requesting client >>> + his master latency to the server then divided by two - with SDR you >>> control the network (and the paths). >>> >>> > that the server is running >>> >>> Tweaking steamclient to be more happy with sharing alive updates (30s >>> heartbeats) with the GMS would probably do the trick for stale >>> information. It's not like it needs to be super up to date (although it >>> could impact the "wait for a server slot" feature). >>> >>> Just a thought, anyway. >>> >>> Kyle. >>> >>> On Tue, Nov 17, 2020 at 12:23 PM Fletcher Dunn < >>> [email protected]> wrote: >>> > >>> > The GMS does indeed have all of this information. >>> > >>> > Let me investigate moving more data to be in the GMS reply, instead of >>> being returned in A2S_INFO. >>> > >>> > I think some ping will always be necessary to measure the latency and >>> confirm UDP connectivity and that the server is running. But there are >>> probably some simple changes that can be made to reduce the size of these >>> replies significantly and move them to the GMS. >>> > >>> > -----Original Message----- >>> > From: Kyle Sanderson <[email protected]> >>> > Sent: Tuesday, November 17, 2020 11:38 AM >>> > To: [email protected] >>> > Cc: Fletcher Dunn <[email protected]> >>> > Subject: Re: [Csgo_servers] RFC: Changes to the A2S_INFO protocol >>> > >>> > > However, I am currently working on integrating SDR functionality >>> > > with the server browser, and so while I am touching this code, it >>> seemed like the right time to address this longstanding issue. >>> > >>> > Ahha! If we're already in there making other changes - I'd like to >>> propose something else then. >>> > >>> > 1. Lets promote the GMS (if this still exists) to have all server >>> information (players, rules, etc). >>> > 2. Have steamclient default to leaving old queries enabled, but the >>> games themselves with a convar to disable old queries by default. >>> > 3. This way technically the client doesn't have to ping the server (I >>> mean - it should still A2A_PING at some point), and tiny GSPs won't have to >>> deal with conntrack as much. >>> > >>> > I think this is what was done with the old master > GMS flip(?) - same >>> idea here. There can be a huge win because the GMS can immediately return >>> all these results to the client (or pages - whatever), without destroying >>> the conntrack table on bad home appliances. Simple stream, challenge, >>> response with the full rendered list. "Steam Desktop Client" can still do >>> the full query in the favourites list, but do a GMS query first for results >>> and if it's missing try hitting it directly. >>> > >>> > WDYT? >>> > >>> > Kyle. >>> > >>> > On Tue, Nov 17, 2020 at 10:00 AM Fletcher Dunn - fletcherd at >>> valvesoftware.com (via csgo_servers list) < >>> [email protected]> wrote: >>> > > >>> > > John! Good to hear from all old folks from years ago! >>> > > >>> > > >>> > > >>> > > TL/DR: New proposal: the server requires all 3 connectionless >>> packets from clients to be at least 1200 bytes. >>> > > >>> > > >>> > > >>> > > I’ve gotten similar feedback from a few people now. The only reason >>> to consider allowing a smaller packet with a challenge is to give the >>> client a way to reduce the bandwidth sent when pinging a ton of servers. >>> But doing this would impair the ability to filter out these packets further >>> out, and it is also more complicated to implement. (I wasn’t planning on >>> changing the server browser in steamclient.dll to do it, I was just going >>> to do the simple thing of padding the packet.) Given that it is 2020 The >>> Year of Our Lord Gaben, probably the extra bandwidth needed to ping a bunch >>> of servers is just not significant. >>> > > >>> > > >>> > > >>> > > Regarding 1200: although this technically maybe not OK according to >>> RFCs from the mid 90’s, being larger than the absurdly small minimum IPv4 >>> MTU, I believe it is OK in practice in 2020 TYOOLG, especially since the >>> minimum MTU for IPv6 is 1280. In the SDR protocol used by CSGO and Dota, >>> clients always initiate their communication with a 1200 byte packet, and >>> that has not caused any problems. >>> > > >>> > > >>> > > >>> > > To Kyle Sanderson’s point: I realize that this is not the most >>> pressing issue facing the Internet today. However, I am currently working >>> on integrating SDR functionality with the server browser, and so while I am >>> touching this code, it seemed like the right time to address this >>> longstanding issue. However, Valve is very sensitive to breaking old >>> games. It’s my understanding that this plan allows old games to continue >>> to operate, even if the code cannot be updated. If I’m mistaken, let me >>> know. >>> > > >>> > > >>> > > >>> > > From: John <[email protected]> >>> > > Sent: Tuesday, November 17, 2020 9:38 AM >>> > > To: [email protected] >>> > > Cc: Fletcher Dunn <[email protected]> >>> > > Subject: Re: [Csgo_servers] RFC: Changes to the A2S_INFO protocol >>> > > >>> > > >>> > > >>> > > Fletcher, >>> > > >>> > > This sounds like a reasonable idea. >>> > > >>> > > Of the two, requiring a large request (#1) might be best. Both #1 >>> and #2 help with reflection attacks, but #1 also helps to mitigate directly >>> spoofed query attacks on game servers. There is less overhead involved on >>> the server side with rejecting an improperly sized packet than in >>> generating a randomized challenge response and having to locally store that >>> state; and, should the spoofer generate properly-sized packets, they would >>> be limited to a lower overall packet rate (which also drastically reduces >>> overhead on the server side). Further, an external firewall could easily >>> drop improperly-formatted packets based on size, cutting out many attacks. >>> > > >>> > > (By the same token, connection and all other unsolicited packets >>> > > should probably also be required to be large.) >>> > > >>> > > The only real downside would be that tools would need to be updated. >>> I don't see a blocker there. >>> > > >>> > > The specific size of the packets isn't too important as long as it >>> beats lowest-common-denominator MTUs. 800-1200 should be fine. >>> > > >>> > > One other consideration here is whether this can be coupled with >>> changes designed to mitigate the negatives of proxied responses (some hosts >>> have taken to advertising their prefixes from multiple PoPs and proxying >>> query responses in order to fake lower latencies, which degrades the player >>> experience). I can't immediately think of a good mechanism for that in the >>> query protocol itself; the primary way to deal with it would seem to be at >>> the global level, by penalizing servers whose latencies are measured to be >>> low from multiple locations in an impossible way. >>> > > >>> > > -John >>> > > >>> > > On 11/16/2020 5:21 PM, Fletcher Dunn - fletcherd at >>> valvesoftware.com (via csgo_servers list) 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/ >>> > >>> >>> _______________________________________________ >>> To unsubscribe, edit your list preferences, or view the list archives, >>> please visit: >>> https://list.valvesoftware.com/ >> >> >> >> -- >> Dave Parker '11 >> Database & Systems Administrator >> Utica College >> Integrated Information Technology Services >> (315) 792-3229 >> Registered Linux User #408177 >> >> _______________________________________________ >> 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/ > -- Dave Parker '11 Database & Systems Administrator Utica College Integrated Information Technology Services (315) 792-3229 Registered Linux User #408177 _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/
