[Csgo_servers] Steam Client beta released with changes to the A2S_INFO protocol

[via csgo_servers list]

A Steam client beta has just been released, with the following change notes 
relevant to the A2S_INFO discussion:

Server Browser

*   Server browser packets (A2S_INFO, A2S_PLAYER, A2S_RULES) sent by 
clients will now be at least 1200 bytes. (For more details, see 
https://steamcommunity.com/discussions/forum/14/2989789048633291344/) Third 
party tools that send these packets are especially encouraged to read this 
thread.)

*   Improved gameserver challenge generation to harden against certain DoS 
attacks

https://steamcommunity.com/groups/SteamClientBeta/announcements/detail/2896339990496271925

Also, if you use the steamclient.dll/.so with that beta, you can activate the 
new, stricter message handling on the gameserver by setting the environment 
variable STEAM_GAMESERVER_MIN_CONNECTIONLESS_PACKET_SIZE=1200

This is just the beta steam client, not the full public release.  Only a set of 
users will be using this client, and we are not quite to deployment step #1 
described below.



From: Fletcher Dunn
Sent: Monday, November 16, 2020 4:47 PM
To: 'hlds_annou...@list.valvesoftware.com' 

Subject: RFC: Changes to the A2S_INFO protocol

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: 0x
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 post it to 
hlds_annou...@list.valvesoftware.com.
  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/

Re: [Csgo_servers] RFC: Changes to the A2S_INFO protocol

[David Parker]

Ah yes, I see it now.  Thank you Marco for that breakdown.

On Wed, Nov 18, 2020 at 3:00 AM Marco Padovan  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  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) <
>> csgo_servers@list.valvesoftware.com> 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 
>>> Sent: Tuesday, November 17, 2020 1:15 PM
>>> To: Fletcher Dunn 
>>> Cc: csgo_servers@list.valvesoftware.com
>>> 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 <
>>> fletch...@valvesoftware.com> 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 
>>> > Sent: Tuesday, November 17, 2020 11:38 AM
>>> > To: csgo_servers@list.valvesoftware.com
>>> > Cc: Fletcher Dunn 
>>> > 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 

Re: [Csgo_servers] RFC: Changes to the A2S_INFO protocol

[Marco Padovan]

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  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) <
> csgo_servers@list.valvesoftware.com> 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 
>> Sent: Tuesday, November 17, 2020 1:15 PM
>> To: Fletcher Dunn 
>> Cc: csgo_servers@list.valvesoftware.com
>> 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 <
>> fletch...@valvesoftware.com> 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 
>> > Sent: Tuesday, November 17, 2020 11:38 AM
>> > To: csgo_servers@list.valvesoftware.com
>> > Cc: Fletcher Dunn 
>> > 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