Page 6 of 11

Re: BaseJKA Security Fix

Posted: Thu Sep 27, 2007 4:59 pm
by 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 :P
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.

Re: BaseJKA Security Fix

Posted: Thu Sep 27, 2007 7:10 pm
by Gamall
cybermaniac wrote: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:
Gamall wrote:messages from the dedicated server have been made slightly more visible: the tag is now [SERVER], with colors.
:n on the other hand, the /svsay command can't be altered, as it is hard coded into jampded instead of jampgame.
cybermaniac wrote: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 :P
cybermaniac wrote: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.
cybermaniac wrote: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 :?
cybermaniac wrote: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" :)

Re: BaseJKA Security Fix

Posted: Thu Sep 27, 2007 8:38 pm
by cybermaniac
Gamall wrote:
cybermaniac wrote: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

Re: BaseJKA Security Fix

Posted: Thu Sep 27, 2007 9:39 pm
by 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.

Re: BaseJKA Security Fix

Posted: Thu Sep 27, 2007 11:01 pm
by cybermaniac
Gamall wrote: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?

Re: BaseJKA Security Fix

Posted: Fri Sep 28, 2007 4:16 am
by 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.

Re: BaseJKA Security Fix

Posted: Fri Sep 28, 2007 8:08 am
by Gamall
Hello,
ensiform wrote: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 :)
ensiform wrote: 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 :?.

Re: BaseJKA Security Fix

Posted: Sun Sep 30, 2007 4:35 am
by ensiform
Gamall wrote: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. :bobo

Re: BaseJKA Security Fix

Posted: Sun Sep 30, 2007 12:01 pm
by Gamall
Ok :?

Thanks for clearing that out.



So...
John Preston wrote: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.

Re: BaseJKA Security Fix

Posted: Sun Oct 07, 2007 2:22 pm
by 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 783 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)

Re: BaseJKA Security Fix

Posted: Sun Oct 07, 2007 7:11 pm
by 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.

Re: BaseJKA Security Fix

Posted: Tue Oct 09, 2007 8:51 am
by 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";
	}

Re: BaseJKA Security Fix

Posted: Tue Oct 09, 2007 11:20 pm
by 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 :)

Re: BaseJKA Security Fix

Posted: Wed Oct 10, 2007 6:45 pm
by John Preston
:modo
indeed.

Gamall, update 1st post of this topic please.

Re: BaseJKA Security Fix

Posted: Wed Oct 10, 2007 6:56 pm
by Gamall
John Preston wrote: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.