[Jagged (old)]

Just wanted to pass on this new vulnerability for other server admins:

http://www.securityf...07/2005-02-13/0

I have an updated 1.32b linux binary, or you can download and compile the updater on the link above.

-Jagged

[HoboHumpinSlut (old)]

too bad that binary is anything but official

[6th|illogical]

Can't sleep, read this. The issue has been around. I'd like to think that the gaming community is beyond that type of "attack", but it is still best to run your server within some type of auto-restarting script or have it checked every 5 minutes or so. If it becomes a problem I think an iptables ruleset could be cooked up to block it.

*Running an un-official patch on your server is NOT SUGGESTED*

[Jagged (old)]

I would agree, however an autorestart script doesn't do much good if the server is being continuously attacked. Luigi kindly provided the source for the updater, and as you can see it modifies only one byte.

I highly doubt we'll see an official patch from id for this bug.


Think all you want about the community, but there are people out there who will gladly take advantage of this to crash a server. This is especially bad if it happens mid-match.

[rashly (old)]

What file does the match modify? Will this create unpure errors?

If the above doesn't, then I would much, much rather have this patch running on our server than not. Having a crash during a match is not a good thing.

[6th|illogical]

It modifies the Quake 3 binary. Now, whether or not this creates unpure errors or peaks PB's curiousity is something entirely different. If it doesn't, well that's a whole other problem (clans modifying the binary for certain things that work to their advantage). With a little creative programming and address table changing, anything is possible.

[6th|illogical]

The following iptables rules require the string match module. Note that the the string match module is case sensitive (I'm working on that). This should have no problem dealing with the overflow.

iptables -I INPUT 1 -p udp -m mport --dports 27960 -m string --string "xffxffxffxffgetstatus" -m length --length 50:inf -j DROP
iptables -I INPUT 1 -p udp -m mport --dports 27960 -m string --string "xffxffxffxffgetinfo" -m length --length 50:inf -j DROP

Rule goes at the top of the INPUT chain, checks stuff that is UDP and going to port 27960 (add more by tacking them on with commas, no spaces). If the packet contains a status or info request and is larger than 50 bytes (reasonable), toss it.

[Jagged (old)]

Quote

What file does the match modify? Will this create unpure errors?

If the above doesn't, then I would much, much rather have this patch running on our server than not. Having a crash during a match is not a good thing.

It modifies the q3ded binary. It does not cause unpure errors nor does pb check the q3ded.

[rashly (old)]

Good. Thanks Jagged. I am glad that this is on my server.

[Jagged (old)]

Quote

The following iptables rules require the string match module. Note that the the string match module is case sensitive (I'm working on that). This should have no problem dealing with the overflow.

iptables -I INPUT 1 -p udp -m mport --dports 27960 -m string --string "xffxffxffxffgetstatus" -m length --length 50:inf -j DROP
iptables -I INPUT 1 -p udp -m mport --dports 27960 -m string --string "xffxffxffxffgetinfo" -m length --length 50:inf -j DROP

Rule goes at the top of the INPUT chain, checks stuff that is UDP and going to port 27960 (add more by tacking them on with commas, no spaces). If the packet contains a status or info request and is larger than 50 bytes (reasonable), toss it.

Definately worth looking into, however the string matching module does not work on kernels =>2.6.0 (at least according to what documentation I can find). Also, the patch-o-matic-ng that this is part of contains some pretty experimental modules.