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/