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
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.
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
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.
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
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
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.