[3spades]

Dondon if that was directed at me I was posting the rwhois so you can bitch to DeltaAnime who the ip block is listed as the owner of.

[Rambetter]

I would take dondon's comments with a grain of salt; he's buddies with Jarou, lenny and solitude.  He's just trying to troll.

[GlaD-don]

I'm just trying to show that you need to do a tracert to find where a server is located. Solitary and Kenny did not ask me to defend them, and I've only talked to Yarou like once, when he asked to join T mooonths ago. And actually I'm not even defending anyone, just pointing out the facts.

[mitsubishi]

This is quite serious now that it is exposed here.

I suggest taking immediate action on this.

(having nooblets kicking the admin(!) without veto power isn't little)

[MaJ]

I've known about this issues for a while in the q3 engine. The problem is that when receiving an rcon, the checks to see if the last rcon was more than 500ms in the past and if not, drops the rcon packet regardless of who it is from. Last night the skv Clan Server (208.43.49.161:27960) was flooded by both spamming rcon, not allowing legitimate rcons through, and fake (zombie) players connecting. This was done from the IP: 67.239.50.46

The person joined the server to flaunt the fact that they could flood the rcons and was subsequently kicked/banned by an admin adding the IP to the banlist and spamming a good rcon to kick the offending player. This is not an optimal solution to this as a good enough flood will prevent any rcons and you would have to wait for a map change to stop the zombie players and offender from being in the server. Even while banned, someone can flood the rcon from that IP so this does not solve the issue.

You can see in this snippet both the fake players and rcon flood:

Client 887 connecting with 100 challenge ping
ClientConnect: 18
ClientUserinfo: 18 ip67.239.50.46challenge-1795035353qport59552protocol68cl_guidA0E16EBCB081879F4E9FE56814608DFCsnaps10rate1500namedvD1gZj8Nizwmodelnone
ClientUserinfoChanged: 18 ndvD1gZj8Nizwt3r2tl0f0f1f2a00a10a20
broadcast: print "dvD1gZj8Nizw^7 connectedn"
Client 888 connecting with 100 challenge ping
Bad rcon from 67.239.50.46:
cvarlist
Bad rcon from 67.239.50.46:
cvarlist
Bad rcon from 67.239.50.46:
cvarlist
Bad rcon from 67.239.50.46:
cvarlist
Bad rcon from 67.239.50.46:
cvarlist
Bad rcon from 67.239.50.46:
cvarlist
Bad rcon from 67.239.50.46:
cvarlist

To prevent this issue, others above have suggested removing the time limit all together. I find this solution to be a little bit of an overkill. To solve this issue on the fly we can check to see if the rcon is good. If so, only delay 20ms otherwise delay something big like 800ms to keep the logfile from being flooded too much. This will give correct rconpasswords much more priority over bad ones at the expense of some cpu time to compare the rconpassword to the one sent in. This fix was coded at 4am so don't expect it to be as elegant as it should but I've tested it pretty extensively while flooding with no issues.

Open server/sv_main.c
Find:

	// TTimo - https://zerowing.idsoftware.com/bugzilla/show_bug.cgi?id=534
	time = Com_Milliseconds();
	if ( (unsigned)( time - lasttime ) < 500u ) {
		return;
	}
	lasttime = time;

	if ( !strlen( sv_rconPassword->string ) ||
		strcmp (Cmd_Argv(1), sv_rconPassword->string) ) {
		valid = qfalse;
		Com_Printf ("Bad rcon from %s:n%sn", NET_AdrToString (from), Cmd_Argv(2) );
	} else {
		valid = qtrue;
		Com_Printf ("Rcon from %s:n%sn", NET_AdrToString (from), Cmd_Argv(2) );
	}

Replace with:

	time = Com_Milliseconds();
	if ( !strlen( sv_rconPassword->string ) ||
		strcmp (Cmd_Argv(1), sv_rconPassword->string) ) {
		valid = qfalse;

		// MaJ - If the rconpassword is bad and one just happned recently, don't spam the log file, just die..
		if ( (unsigned)( time - lasttime ) < 800u ) {
			return;
		}

		Com_Printf ("Bad rcon from %s:n%sn", NET_AdrToString (from), Cmd_Argv(2) );
	} else {
		valid = qtrue;

		// MaJ - If the rconpassword is good, allow it much sooner than a bad one.
		if ( (unsigned)( time - lasttime ) < 100u ) {
			return;
		}
		Com_Printf ("Rcon from %s:n%sn", NET_AdrToString (from), Cmd_Argv(2) );
	}
	lasttime = time;

You can download a binary with this patch applied here should you not have the capabilities to build it.

This might not be the best solution but it does the job. Hopefully this helps you guys as it appears this exploit is now in use in the wild. I'm open for suggestions for improvements or issues people have.

[Rambetter]

Thank you for your post MaJ.

A code change along the lines of what you suggest seems like a pretty plausible fix.  I will analyze your changes shortly and potentially apply them to my server code too.

I just wanted to clarify some things based on what you said in the previous post.

1. If you want real power during an attack situation, I recommend using the server console directly if you have access to it.  There is no floodprotext or wait time when you issue commands directly into the server console.  You can issue the "addip x.y.z.q" command and then "kick N" to ban a zombie player from the server console.  As far as banning rcon commands from a particular IP address, seems that you are attempting to make some code changes to address that issue.
2. Being connected as a player to a game server and issuing an rcon command to that same server are two separate things.  You DO NOT need to be a player in the server to issue an rcon command.  The rcon is a different protocol over a different channel.  There are standalone tools (such as multircon written by Luigi) that you can use to issue rcon commands without being a player in a server.  It is quite easy to write little programs that flood rcon on a remote server.  You state that waiting for a map change would allow you to issue an rcon command finally, although the map change would not improve the situation; the remote program issuing rcon commands will not stop because of a map change.

[|ALPHA|CCCP]

Ramb I'll <3 you long time if you can share i386 and x86_64. I am still quite C illiterate, but I'm trying to learn...slowly. Thank you for the posts guys !

[Rambetter]

MaJ - I analyzed your code changes and I like them.  Unless I am a real doofus they seem to be pretty solid.  But let me add some obervations.

First, the ioquake3-1.36 code, which was released this week, does not have this issue fixed.  It's still got the bug.

Second [this is a minor issue, but] I would change the 20 milliseconds to something greater just to prevent someone who does know rcon from spamming the logs too much.  It's not really that big a deal though.

Here's some analysis regarding your code changes.  Let's say you keep the 800 millis timeout for bad rcon and put 200 millis timeout for good rcon.  Let's say an attacker is spamming bad rcons almost an infinite number of times per second.  At some point, a good rcon will be issued.  So, the value of "time - lasttime" will be a random value between 0 and 800 at the time the good rcon is issued.  If the good rcon timeout is at 200 millis, the chances of the good rcon succeeding is three out of four, which is not too bad.

Your code change - the only real drawback CPU-wise I see is making the rconpassword string comparison on every rcon attempt.  Is this an issue do you think?

For the final say-so regarding whether this fix will be "accepted" by the community, you will need to get woekele's approval and get him to post a link of the compiled binaries and source code.  I will PM him now.  In the meantime I will post the complete ioUrT server source code here, with the previous callvote exploit patch included.

I'm adding your change with slight modifications in the timeout values:

        // TTimo - https://zerowing.idsoftware.com/bugzilla/show_bug.cgi?id=534
        time = Com_Milliseconds();
        if ( !strlen( sv_rconPassword->string ) ||
             strcmp (Cmd_Argv(1), sv_rconPassword->string) ) {
          // MaJ - If the rconpassword is bad and one just happned recently, don't spam the log file, just die.
          if ( (unsigned)( time - lasttime ) < 500u ) {
            return;
          }
          valid = qfalse;
          Com_Printf ("Bad rcon from %s:n%sn", NET_AdrToString (from), Cmd_Argv(2) );
        } else {
          // MaJ - If the rconpassword is good, allow it much sooner than a bad one.
          if ( (unsigned)( time - lasttime ) < 100u ) {
            return;
          }
          valid = qtrue;
          Com_Printf ("Rcon from %s:n%sn", NET_AdrToString (from), Cmd_Argv(2) );
        }
        lasttime = time;

Complete source code for the ioUrTded server, previous callvote exploit patches included:
http://daffy.nerius....hedserver_2.zip

[MaJ]

Quote

You state that waiting for a map change would allow you to issue an rcon command finally, although the map change would not improve the situation; the remote program issuing rcon commands will not stop because of a map change.

Sorry if I wasn't clear. After adding a player to the banlist.txt manually they obviously aren't banned immediately. However, on map change the banlist is loaded again and all players reconnect. At that point g_filterPacket is called to compare the player's ip to the banlist. At that point the player is not allowed back in.

Quote

Your code change - the only real drawback CPU-wise I see is making the rconpassword string comparison on every rcon attempt.  Is this an issue do you think?

I mentioned that it would take some CPU time. This may have been an issue with very slow, home servers but a string comparison is nothing to a modern CPU and should have no effect. I flooded my relatively slow, athlon 3800+ server and it held up just fine.

Quote

For the final say-so regarding whether this fix will be "accepted" by the community, you will need to get woekele's approval and get him to post a link of the compiled binaries and source code.

Fine with me, I just wanted to let everyone know that this issue is becoming more widespread than we thought and give a possibility for a patch. I'm sure there are some optimizations that I missed when compiling it. Hopefully this exploit won't be around in the 4.2 server binary as many people still haven't even patched for the callvote exploit.

Quote

Second [this is a minor issue, but] I would change the 20 milliseconds to something greater just to prevent someone who does know rcon from spamming the logs too much.  It's not really that big a deal though.

If I've given someone rcon they can do a lot worse than spamming the log file..."touchFile" comes to mind. It could take some tweaking but I don't really see any benefit for my server to have it higher. Others may wish there to be a bigger delay on success. A bigger delay would also make it harder to bruteforce a password. Hopefully nobody is using a weak password but I suppose a bigger delay like 200 for good passwords, 1000 or more for bad would be just fine and allow an admin to keep control of the server. I haven't tested how many good rcons can get through in a flood situation using these values but it should be fine as you stated. I'd be willing to say 2 or more seconds on bad would be acceptable

Hopefully your exploration of this issue will squash the bug so no other servers will be exploited.

[mitsubishi]

Consider not having a check at all, for CPU cycles saving sake, though maybe an overkill of optimization. Also, why would you flood protect for an rcon? He is usually a behaved person.