I’m not aware if this bug has been found before but if it hasn’t. Here’s what I have found so far, hopefully someone can verify this and maybe tell me a little about what I have found or *cough* fix it, Valve? ;)

 

If you send a command via rcon to a Source server that requires the server to send many packets back to the client via TCP you can cause the server to lock up.

I used the command “cvarlist” for this.

 

First send the rcon command to the server.

Then listen for the data from the server but do not start clearing the socket or read it slowly.

Check if your server is still responding. ;)

 

From what I can assume, this seems to cause the server to keep checking the socket to see if the data has been accepted before sending anymore (Possibly a DDoS protection?) however, the server seems to be very single minded on this and will get stuck in an infinite loop, thus causing it to lock up. The only fix the admins of the servers I have locked up so far have found is killing the process and starting again.

 

From what I have found so far, this only applies to the rcon protocol most likely because it is TCP unlike the query protocols.

 

It really isn’t much of a security problem as you would need to auth successfully before the server starts responding to a “cvarlist” and if you can auth you already have the power to just send “quit” but for developers that write buggy code like myself, this does become a pain when servers suddenly start dying while you’re trying to implement the rcon protocol into your code. :P

 

I found this using a PHP script, using fgetc (slow) to get the data but I believe it can be recreated in any language that has some power with sockets.

 

I have tried this on both HL2mp and CS:S servers and the effect is the same.


--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.8.5 - Release Date: 03/02/2005

Reply via email to