POTENTIONAL FIX: etded.x86 getstatus exploit

(system) #1


since a few months there is a exploit floating around abusing the getstatus requests to launch dos attacks against random targets and as a side effect creating massive lags on clients and the server.
Cause of this Yada from Staatsschutz.org made a patch for linux wich reduces the effectivity of this exploit.

etfix_getstatus 0.2 by yada / staatsschutz.org / jan. 2011

This patch will ratelimit etded.x86 2.60b getstatus requests to 1 per IP every
4 seconds. This approach is not ideal as the real fix would be to change the
protocol to require some kind of handshake but this would break compatibility
with existing clients so its not really practical. The worst part is that the
patch is (in theory) vulnerable to a dos where legitimate clients could be
denied access to the getstatus command but i feel this is less of a headache
than kiddies using the server to flood random targets and thereby lagging the
server and pushing bandwith usage through the roof (master server is excluded
from ratelimit so no need to worry about it being denied using spoofed

Download the file right here.

A readme.txt, the sourcecode and a small howto are included.

Your free to distribute this file.

(Paul) #2

Nice fix! I guess this requires some serious skills!

Is this also confirmed working in combination with the ET2.55+ patch?

(system) #3

It is not confirmed since it is only tested with 2.60B.
But if 2.55+ is build upon 2.60B, wich we assume, it should not make any difference.

Feel free to test it.

(dutchmeat) #4

I don’t think it will work on 2.55+ because of the fact that it’s using a fixed file size and memory addresses. Btw, isn’t 2.60B the same version of the released full sourcecode ? In that case a source fix will be better with compiled binaries to share, together with the q3dirtrav fix, buffer overflow fixes and others.

(system) #5

2.55+ is very likely 2.60b with the protocol check removed - the gpl source lacks pb support

(Paul) #6

I’ll test it somewhere soon :slight_smile:

(system) #7

Ok thanks, give us some feedback :slight_smile:

edit: my answer was retarded yesterday :wink:

(zbzero) #8

I have today discovered some ips are doing many getstaus requests from my game servers. After check the ips who have doing theses requests i got these results: -> 77 requests per second -> 200 requests per second

The first one is from China, but the second one is from USA and after search for this ip i found a strange info point me to the nyc.xfactorservers.com

So im really worried why the hell a game server company is doing that and flooding the servers with 200 getstatus requests per second. This is the worse merchandising i ever saw in my life for a company!!

I recommend all the servers owner to block those ips in their servers.

($omator) #9

and what would stop “them” from moving to another ip?

(ailmanki) #10

ipv6 not .

(system) #11

It’s probably a spoofed packet. I don’t have much of a clue about this kind of stuff but this might explain it:

edit: oh and btw. zbzero, those ip’s i see too.
Try to use the patch if your gameservers box is linux. It should bring down the request pretty much.

(schnoog) #12

Because the patch is only working on ET, I wrote a little script to block those attacks with the linux packetfilter iptables for each Q3-Engine game.
You can get the script here: http://www.wolffiles.de/index.php?forum-showposts-44-p1#144
You can set a limit of X / Requests per second. If an offender break the limit, packets from him will be dropped.

(zbzero) #13

Dutchman, i use the patch before and for some unknow reason (i cant undertand) my server has strange lags, and after i replace the patched file for the default binary my lags stops (i means lags for players not in a rcon program, like rconunlimited).

(system) #14

Zbzero, sorry i don’t know any issues about lags so i cannot explain it :frowning:

@Schnoog, nice dude. If Zbzero is right about the lags, wich he probably is when he tested it, your script is a great replacement for the fix :slight_smile:

(system) #15

Oh btw. Schnoog, you should contact a Splatterladder admin so they add your site to import your news.
You have better news then their current rtcwmap.de source.

This way your firewall rules will be spread around some more :slight_smile:
(I only know that they prefer css2 feeds…)

(schnoog) #16

BTW, the fix shouldnt make the server laggy. tbh, Im not a crack with the gameengine, but
let us imagine a server is queried 10000 time / s from 50 Sources (even if they are faked)
the gameserver have to manage a hugh amount of queries and have to decide if such a query should be answered or not (was a getstatus query from this source answered within the last 4 seconds).
Even if no getstatusResponse is send, the gameserver-engine have to handle it.

At this point, IMO, my iptables script counts:
It runs beside the gameserver (in my case a niced cron job is runned every 5 minutes), only “watching” the packet flow without interrupting, and only if the configured limit is broken the iptables rule is set.
From this moment, the iptables packetfilter will drop the incoming packets from this source. It`s kernel-based, so the full system resources are available for this, and not only a forked part of the system (extremly differences when a non-single core system is used to host the gameserver).

(twt_thunder) #17

he… only thing i get out of this is that this thing prob could fix my lag on servers… but i dont get it how to do it… could anybody make a linux patch file or something that we dumbasses can use?

(system) #18

If you mean the firewall rules from schnoog, then first make sure your server has IPTABLES installed.
Then download Schnoog’s script: http://wolffiles.de/index.php?filebase&fid=3042

Unpack the Q3_Getstatus_Exploit_IPTables_Fix_V1_2.sh file.
Be sure it is executable. If your not sure, just chmod +x Q3_Getstatus_Exploit_IPTables_Fix_V1_2.sh.
Then you should be able to run it with ./Q3_Getstatus_Exploit_IPTables_Fix_V1_2.sh

Depending on your distro, you can or should automatically run it every now and then with a cronjob.

btw. Schnoog, maybe only use lower letters for the scriptname :slight_smile: If you type it all without using tab, it’s a freaking pain in the ass :wink:

(zbzero) #19

my clan has ET servers in UK and the members are from the all parts of world, for the players who have ping less then or equal 100 its ok they didnt see too many differences but for players who have pings like 200 it causes a lot of difference, maybe its a mistake from my part the patch cause the lags or not, but i have sure what im saying after i put the old binary file (unpatched) all my players have reported a better connection and no lags so frequently like before.

(schnoog) #20

because some problems, reported by old-owl, occoured, I had to change the script a little bit.
Now there should be no problem, running the script as a cronjob.
If you have any problem with the 1.2 version of the script, I recommend the updated V1.3 (lowercase-named).
all about the script can be found here http://wolffiles.de/index.php?forum-showposts-44-p1#154