BaseJKA Security Fix

[cybermaniac]

ok then

here's my verdict thus far.


when you do "svsay hello" for eg, the server still comes up as "^7Server:" (not coloured tags or whatnot - that only comes up when server is changing settings).

donotallowkataspin works perfectly, don't worry about the "screen shake", as that way no1 will notice the actual thing is disabled
time works fine
info i didn't have the chance to try, but i'm sure someone can test it with a linux version so i wudn't worry too much about that
namelength works absolutely fine

is there a way to log what the rcon is saying/doing?


logs side of things looks fine:

Code: Select all

[Thu Sep 27 15:48:12 2007]  Renamed: (client 2 []) <^1<<^7TMA^1>>^3Faker> --> <^1^^0Beowulf>
[Thu Sep 27 15:48:12 2007]  ClientUserinfoChanged: 2 n\^1^^0Beowulf\t\1\model\jedi_zf\c1\4\c2\4\hc\100\w\0\l\0\tt\0\tl\0\siegeclass\Jedi Duelist\st\single_5\st2\single_5\dt\0\sdt\1
[Thu Sep 27 15:48:17 2007]  Kill: 1022 0 38: <world> killed Alora by MOD_FALLING
[Thu Sep 27 15:48:53 2007]  Renamed: (client 2 []) <^1^^0Beowulf> --> <qwertyuiop>

"qwertyuiop" was my excercise with the namelength (limit of 10 chars)


everything looks pukka from the changes you made by the looks of it.

[Gamall]

when you do "svsay hello" for eg, the server still comes up as "^7Server:" (not coloured tags or whatnot - that only comes up when server is changing settings).

Like I said in the changelog:

messages from the dedicated server have been made slightly more visible: the tag is now [SERVER], with colors.
on the other hand, the /svsay command can't be altered, as it is hard coded into jampded instead of jampgame.

info i didn't have the chance to try, but i'm sure someone can test it with a linux version so i wudn't worry too much about that

Errr... it works fine under windows You just have to change/add the information cvar in your server.cfg

is there a way to log what the rcon is saying/doing

Yes there is: add the line "developer 1" to your server.cfg and all queries shall be logged by the server console (not the regular logs though).

Then, redirecting jampded.exe's standard output to some file will create RCON logs.

This is the only way: it cannot be modded, since it is hardcoded into jampded, which is closed-source, as opposed to the jampgame component.

logs side of things looks fine:

Err, the IP should be between the []. Did you remove it ? Sometimes, for some reason, the IP seems to not be in the userinfo

everything looks pukka from the changes you made by the looks of it.

After looking up he meaning of "pukka" in an online dictionary, I think I can safely answer "thanks"

[cybermaniac]

logs side of things looks fine:

Err, the IP should be between the []. Did you remove it ? Sometimes, for some reason, the IP seems to not be in the userinfo

nope - i didn't remove the IP from there - that was a direct c+p

[Gamall]

Hmmm.

Most of the time it should work. I have never been able to duplicate that bug on any of my servers, though I have seen it twice on other peoples logs.

If the IP escapes the userinfo (which it should not) it is not really a bug on my side anyways... So I don't think I can fix it, unless the IP is stored in another location too.

[cybermaniac]

Hmmm.

Most of the time it should work. I have never been able to duplicate that bug on any of my servers, though I have seen it twice on other peoples logs.

If the IP escapes the userinfo (which it should not) it is not really a bug on my side anyways... So I don't think I can fix it, unless the IP is stored in another location too.

maybe its worthwhile stealing sum1 elses server config to see what might be the issue?

[ensiform]

FYI the ip in the userinfo is only reliable during ClientConnect (usually only the first connect) due to a bug in the version of the engine plus thereafter a client can spoof that value with setu command anyway. Also if the userinfo string is too big the ip will end up not getting added to the userinfo buffer thus no ip.

[Gamall]

Hello,

FYI the ip in the userinfo is only reliable during ClientConnect (usually only the first connect) due to a bug in the version of the engine plus thereafter a client can spoof that value with setu command anyway.

I copy the IP in another place during ClientConnect, and only ever use said copy afterwards, so this is not a problem

Also if the userinfo string is too big the ip will end up not getting added to the userinfo buffer thus no ip.

That is what I suspected was happening, which I why I asked if the IP was, by any chance, stored in another place -- hopefully more reliable -- than userinfo .

[ensiform]

That is what I suspected was happening, which I why I asked if the IP was, by any chance, stored in another place -- hopefully more reliable -- than userinfo .

Sadly there is not.

[Gamall]

Ok

Thanks for clearing that out.



So...

any news?

Well, since everything that can work seems to work, I'll start wrapping the thing up. I'm on something else this week-end, so it is likely to be for the next.

If the spirit of the GCC god is with me, I'll solve the compile bug under linux quickly and release the thing in no time. If not, I'll keep you posted anyway.

[Gamall]

Well well, it seem I have finally solved that $%£$$ù compile bug under Linux

Test server : 213.251.186.99:29070

.SO file for version 1.1-dev

jampgamei386.so.rar

(1.2 MiB) Downloaded 1072 times

Please report whether is works as it should.

If it does, I'll pack and document it when I get a moment (I am quite busy IRL at the moment)

[cybermaniac]

i'll put it on my server and if i don't report back.........its working.........or the .so file exploded in my face.

[ensiform]

Btw there are some other userinfo things you can take into account...

1) trap_GetUserinfo should not give a string that has a length of less than 1.
2) trap_GetUserinfo string char [0] must be a \ ( '\\' )
3) trap_GetUserinfo string length-1 must not be a \ ( '\\' )
4) Count up total number of \'s in trap_GetUserinfo string and, that number % 2 should equal 0 otherwise say bad number of slashes.
5) More than 1 instance of \ip\, \password\, \name\, \team\, \sex\, \model\, \forcepowers\, \color1\, \color2\, \saber1\, \saber2\, \rate\, \snaps\ is bad
6) Existance of \cl_guid\ or \cl_punkbuster\ at all is bad (you already do this with the cvars)
7) Check the above upon connect and each ClientUserinfoChange call (likely right after variable declarations)
8) Return with the reason (or kick with reason from CUIC)

This is what I use for # 4:

Code: Select all

	for(i=0;userinfo[i];i++) {
		if(userinfo[i] == '\\') {
			slashCount++;
		}
	}
	if(slashCount % 2 != 0) {
		return "Bad number of slashes in userinfo";
	}

[Gamall]

Er, yes, one could test all that and more but.. why bother ?

I test presence of cl_guid or absence of model for a good reason: those are clearly indicative of a q3fill attack. (and detect 100% of those, while yielding no false positive. The model test could even be done without.)

But why would simple incorrectness of the userinfo matter ? I suppose that if an user connects with an incorrect userinfo (whether caused by their own bad karma or by a malevolent attempt to an attack), it remains their problem. That is to say their game may behave erratically (kyle skin, lost preferences etc), but it won't inconvenience anyone else. Kicking them wouldn't accomplish much... especially if they are not attackers. And if they are, they are harmless anyway.

That is, unless there is an exploit using incorrect userinfo strings, besides q3fill (as far as q3fill is concerned, if someone decides to make a special version, specifically targeting JKA... well, they will succeed and that is all there is to it. No number of tests on userinfo will ever detect the attack if it is well done.), like something crashing/lagging the server when sending incorrect challenges or something. But I am not aware of anything like this. Are you ?


edit: That reminds me I completely forgot to test and fix John Preston's invisible skin exploit. I'll get to it next week end

[John Preston]

indeed.

Gamall, update 1st post of this topic please.

[Gamall]

Gamall, update 1st post of this topic please.

It is up to date... which means, up to the last "final" release, namely 1.0e. It will be updated when 1.1 is released.

edit: I'll be busier than anticipated this weed-end (exams approaching), so I won't have time to fix the invisible skin thing just now.