[Bug] Server prints additional text/RAM content when receiving rcon.

[xrichardx]

Pretty simple scenario:
Linux executable, running in debian 6.0.9 as a dedicated server.
Whenever this server receives a connectionless rcon packet, it prints its content to the console, which is ok. But it seems like the string is not being '\0'-terminated when it is received which causes the server to print out more information until there is a terminating zero in RAM. This can be pretty harmless, e.g. when it produces this:

Code: [Select]

[11:06:54] Rcon from 94.249.253.48:45329:
rcon PASSWORD mapname~(*]--'*[-g'*W[>[=<U[<79be9a831f22a73ea4458
(still, this can be very annoying, for example if you want to read through the logs to find an error)

but it can also print out information that probably should remain hidden:

Code: [Select]

[11:07:36] Rcon from 94.249.253.48:45329:
rcon PASSWORD mapname[@-K<@@-l>>-[@-`@gi@tU0\password\REALPASSWORDHERE\hand\2\name\NoN4Me\skin\male/null\rate\16000\msg\0\fov\120\gender\male"
7f7b63dbb99116e6dd12c6fb8e2e105dee389752a0c3b71e3978ce72260529f45b57c7b81f1365ff6d93831bdef5d2be29d24cc701c0ca1539764fca1dd4bb02ecf88017c3dd418596a260cd8c5e2622fd078eb419d3806d426bba70cf7ac83860ee491c9668a66de4b73d2a1ce22f1b299ab69da09ee45e14b20d06a177ec33e2f770c9737c99e4fefbb2990760ba9cb3f86e50d 43770
this is much more annoying because it prints out much more rubbish, but it also shows data of a random player on the server, including his password, hand and fov setting. I dont exactly know why the server has to have the player's fov, hand and even password in RAM a long time after he connected but that is another problem.

[ViciouZ]

printing memory contents is no worse than the first bug, hostile server owner could be reading passwords anyway. still, nice find

[not_payl_obviously]

I dont exactly know why the server has to have the player's fov, hand and even password in RAM a long time after he connected but that is another problem.

Example for fov usage: Server has option only show visible models, and it needs to know how much data to display.
Example for hand: Server has to know where does ball go out, doesn't it.
Example for password: When you connect you send those vars, how else can server know if you are authorized.
There are much for variables that are sent just because. This is not a big security hole, there are much bigger security concerns (client mostly doesn't validate what commands server gives, thats why jitspoe was able to make screenshot system so easily, and anyone can make malicious server that connecting to will result in malware attack or attacking DP installation to mark it as cheating etc.).

Since to abuse this you have to know rcon password, impact of this bug is minimal.
But next time you might want to inform jitspoe about security issues on email/PM.

[jitspoe]

That passsword is just the password to connect to the server.  Player name, skin, rate, fov, hand, password, and some other things are all client variables sent to the server.  The server controls which skin/name/hand/fov ultimately get used.  The client just requests different things.

In any case, I'll see if I can track down why the string isn't null terminating.

[jitspoe]

Ok, it looks like this isn't possible to repro with a normal client, since the string it sends is null terminated, but I think I've fixed it.  What were you using to send rcon commands?

I've also added the "mapname" cvar to the OK list so you can use cvar_get to retrieve it instead of rcon.

[xrichardx]

The rcon was sent by a pgp-only script that sets expert 8 over and over again. It did not null terminate the command it sends, so there was the error. I made it and now everything is clean as it should be, still, I think for security reasons a network packet should be null-terminated by the receiver and you should not trust the sender.
Getting the mapname via cvar_get is good but won't help me in that situation.

Thanks for your help .

[jitspoe]

Yeah, I've cleaned it up for the next version, so it ensures null termination.  Glad you had a local fix so you don't have to wait for the next version.