Author Topic: Allowing the % character in chat (Read 14881 times)

/dev/humancontroller · « **on:** July 17, 2007, 12:31:44 pm »

Both the tremulous server and clients process the % character and change it to a dot (.), even though the character set does contain a %. That coule be fixed if the server didn't change the %% sequence to a double-dot. And sending a % as %% should be taken care of on the client.

I don't see this allowing any exploitation, and both servers and clients can be individually patched.

Has anyone thought about this?

ShadowNinjaDudeMan · « **Reply #1 on:** July 17, 2007, 12:47:51 pm »

No, why would you want to put % into your messages.

Add this one:

§
so we can say War§ow

and this ±
not sure why.

Caveman · « **Reply #2 on:** July 17, 2007, 01:01:28 pm »

riiight, let the client decide what to send to server so the server does not need to check...

pffffft. Might be your wet dream.

HamStar · « **Reply #3 on:** July 17, 2007, 01:35:34 pm »

And why do we need to use %?

tehOen · « **Reply #4 on:** July 17, 2007, 02:38:10 pm »

it is discussed before
passing "%s" to com_printf with no parameter causes a server crash

kevlarman · « **Reply #5 on:** July 17, 2007, 04:21:19 pm »

Quote from: "tehOen"

it is discussed before
passing "%s" to com_printf with no parameter causes a server crash

com_printf isn't that big a deal, vs_printf on the other hand... (called by va) is in pretty much every section of the server code that the client's input passes through.

/dev/humancontroller · « **Reply #6 on:** July 17, 2007, 04:32:14 pm »

Why would we need any of the characters other than a-z A-Z .-?!() 0-9? We don't ever need them. Remove the other charaters immediately. Hello? Welcome to dumb ideas. Actually we do need them! The more the characters, the better.

Do you know what % is? I think you don't so I'll tell you, it's the percent sign. There is no reason not to add %. True, having no % symbol will cause pain only to new players, because experienced ones have learned to write "percent" instead. We don't need % to save the world, but hey, why not ease the handwork?

As for noobs who don't understand professional server code:
The server already parses and checks every character of sent strings. If it didn't, and accepted any message, then you just told me the newest, best and most powerful hack to crash ALL servers on the internet in just 1 minute. WOW!

tehOen read my post again and again, until it rings a bell, that what I posted is new and hasn't been discussed. Yes, indeed, passing "%s" to Com_Printf without a second parameter does do a crash when compiled with some compilers, but that hasn't happaned in years, because of the professional server code. When a client sends a chat message, like "write this %s", the client first parses the message and changes every single character % to a dot. So in the packet, it is sent as "write this .s". OK, there are hacked clients, so the server never uses unchecked messages, and also checks for every single % symbol. If you know basic C output, then you must know that the printf escape sequence %% prints a single % symbol with NO problem. Therefore it is safe to accept messages with %%.

For example: "kick %HAX% (50% needed)" sent by the (hacked) client will auto change to "kick .HAX. (50. needed)"
And my recommendation is that sending "kick %HAX% (50%% needed)" will change to "kick .HAX. (50%% needed)", and will not do anything to %%, because it safely prints as "kick .HAX. (50% needed)"

tehOen · « **Reply #7 on:** July 17, 2007, 04:36:50 pm »

... why do you want % so badly
type o/o instead

/dev/humancontroller · « **Reply #8 on:** July 17, 2007, 04:42:32 pm »

Quote from: "tehOen"

... why do you want % so badly
type o/o instead

Keyword: improvement.

OK, let's remove the e character that you so often use. Don't ask for to be readded, just write 3 instead.

Odin · « **Reply #9 on:** July 17, 2007, 06:01:49 pm »

Actually I use the % symbol rather often in-game and often have to correct myself after I've sent it. It's kind of annoying.

David · « **Reply #10 on:** July 17, 2007, 06:21:08 pm »

find a fix then?
and make it %%? sure. how about %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%? how many printf's does it go through? I recall someone saying that it was a lot.

The best bet is to replace it with some char <32 and then switch back at the end.

tehOen · « **Reply #11 on:** July 17, 2007, 07:29:17 pm »

Quote from: "/dev/humancontroller"

tehOen read my post again and again, until it rings a bell, that what I posted is new and hasn't been discussed. Yes, indeed, passing "%s" to Com_Printf without a second parameter does do a crash when compiled with some compilers, but that hasn't happaned in years, because of the professional server code. When a client sends a chat message, like "write this %s", the client first parses the message and changes every single character % to a dot. So in the packet, it is sent as "write this .s". OK, there are hacked clients, so the server never uses unchecked messages, and also checks for every single % symbol. If you know basic C output, then you must know that the printf escape sequence %% prints a single % symbol with NO problem. Therefore it is safe to accept messages with %%.

you are so leet. code it for us; come with a patch. until then stop whining. it was in quake3 for years. no one said "omg id please fix it I cant type %" even if they said id didnt fixed it in point releases. so code it for us our leet coder

/dev/humancontroller · « **Reply #12 on:** July 17, 2007, 08:07:39 pm »

Quote from: "David"

find a fix then?
and make it %%? sure. how about %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%? how many printf's does it go through? I recall someone saying that it was a lot.

The best bet is to replace it with some char <32 and then switch back at the end.

It doesn't matter how many passes the string goes through, because the string is read into the output only at the last printf (the printf functions pass pointers to eachother).

Caveman · « **Reply #13 on:** July 17, 2007, 08:30:43 pm »

While you are at it, why not change the code so it will accept all 255 chars?

/dev/humancontroller · « **Reply #14 on:** July 17, 2007, 08:37:39 pm »

Quote from: "Caveman"

While you are at it, why not change the code so it will accept all 255 chars?

Hmm, why not. I'll look into it.

kevlarman · « **Reply #15 on:** July 17, 2007, 09:45:39 pm »

Quote from: "/dev/humancontroller"

Quote from: "David"
find a fix then?
and make it %%? sure. how about %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%? how many printf's does it go through? I recall someone saying that it was a lot.

The best bet is to replace it with some char <32 and then switch back at the end.

It doesn't matter how many passes the string goes through, because the string is read into the output only at the last printf (the printf functions pass pointers to eachother).

not true, it is definitely possible for the result of a printf to go through another printf, in fact i'm almost certain that it does.

/dev/humancontroller · « **Reply #16 on:** July 21, 2007, 09:31:33 pm »

Quote from: "kevlarman"

Quote from: "/dev/humancontroller"
Quote from: "David"
find a fix then?
and make it %%? sure. how about %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%? how many printf's does it go through? I recall someone saying that it was a lot.

The best bet is to replace it with some char <32 and then switch back at the end.

It doesn't matter how many passes the string goes through, because the string is read into the output only at the last printf (the printf functions pass pointers to eachother).
not true, it is definitely possible for the result of a printf to go through another printf, in fact i'm almost certain that it does.

Hey kev, I looked into the Com_Printf() function. It calls va_stuff directly and dumps the output into a 4k buffer, which is raw ASCII with % symbols enabled. It's printed to the console per character from there. It's the same with Com_Error() and others.
Now that's a lot of printf's it goes through...

Code: [Select]

=============
Com_Printf

Both client and server can use this, and it will output
to the apropriate place.

A raw string should NEVER be passed as fmt, because of "%f" type crashers.
=============

So this thread is of some lolzomg. All you have to do is disable the code that tuns % symbols in to dots and it should work with no problem, provided that everyone using Com_Printf will at least read this comment. No %% passing whatsoever, use raw % as much as possible.

Code: [Select]


// translate all fmt spec to avoid crash bugs
//if ( c == '%' ) {
//	c = '.';
//}
// check removed, no need for this shit, because
// only noobs use Com_Printf( str );
// instead of Com_Printf( "%s", str );

%s and other escapes are only recognized in the first argument, called format flags. Using Com_Printf( "%s", "%" ); is totally safe. Outputs a %. Who would code in such a way, that the output ("%") would go into the first parameter of Com_Printf()

kev, you were right about the va output-input stuff. It's the va()'s in function calls.
There is 1 fucked up case:

Code: [Select]

Com_Error (ERR_SERVERDISCONNECT, va( "Server Disconnected - %s", Cmd_Argv( 1 ) ) );
// This is unsafe, and the code should be changed to:
Com_Error (ERR_SERVERDISCONNECT, "Server Disconnected - %s", Cmd_Argv( 1 ) );

For example, the server can crash the (un%protected) client with the command "disconnect fucku%snoob", where the text after disconnect should have been the reason for dropping the client.
About the rest: I've searched all the function call arguments, all use "%s" style, except for 2 fuckexceptions, let's hope they're safe:

Code: [Select]

NET_OutOfBandPrint( NS_SERVER, to, command );
Com_sprintf( scratch, sizeof(scratch), dirptr);

Did i miss anything?

+ Uhm, I think Jedi Academy has % enabled. Can someone who has the game confirm that plz?

[COM-IT]Styx · « **Reply #17 on:** August 18, 2007, 05:19:24 pm »

what about an ascii escape code? will that work?

/dev/humancontroller · « **Reply #18 on:** August 18, 2007, 06:04:52 pm »

benmachine · « **Reply #19 on:** August 18, 2007, 06:12:20 pm »

bumpbump

I patched a client and server and it is working fine - so far.
I'm currently looking for ways in which the client or server could cause problems for each other, accidentally or maliciously

/dev/humancontroller · « **Reply #20 on:** August 18, 2007, 06:54:28 pm »

Quote from: "benmachine"

bumpbump

I patched a client and server and it is working fine - so far.
I'm currently looking for ways in which the client or server could cause problems for each other, accidentally or maliciously

Yes, good. Same thing here (long time ago).

Did you change the % removal in both the msg stuff and the netchan stuff?

tehOen · « **Reply #21 on:** August 18, 2007, 07:56:33 pm »

now fix the real problem
you cant see accented characters anywhere

benmachine · « **Reply #22 on:** August 18, 2007, 08:01:42 pm »

Quote from: "/dev/humancontroller"

Did you change the % removal in both the msg stuff and the netchan stuff?

Nope, and I don't see any such removal. Where is it?
Of course, this whole process woudl be much faster if you could get us patches. We would listen to you a lot more if you could post a patch we could try out immediately.

/dev/humancontroller · « **Reply #23 on:** August 18, 2007, 09:04:26 pm »

About the netchan I was just curious, it's not a removal. The netchan thing is just for message hashing or something like that. As long as it's the same on both client and server sides, that's OK. If different, the server complains about inconsistencies immediately, and the client gets disconnected. But if the % will be allowed in a production release, we should change the netchan stuff too.

If the server and clients have different '%' code in msg.c, I get some really weird effects, I think because of the hash is done on '.' instead of '%' on one side, resulting in wrong hashes and packets being fucked up.

So if you have just commented out the three '%' things in msg.c, that's perfect (your patch is ALMOST good: you forgot to comment out two more). But since it requires the change in the executable, why not change the netchan code too? It would block different clients.

As for testing, there is nothing to be tested with play, just spam lots of messages containing % characters, and it should work without crashes. And if someone knows a way to crash a server through %f messages, tell us.

BTW should I file a Q3 enchancement request to bugzilla?

benmachine · « **Reply #24 on:** August 18, 2007, 09:19:52 pm »

Quote from: "/dev/humancontroller"

(your patch is ALMOST good: you forgot to comment out two more)

Where's yours? You must understand that although it's interesting discussing these matters with you it's incredibly frustrating to receive no real input or contributions. It seems like you've already done the hard work but you aren't sharing it. If you don't know how to use diff, then ask. If you do, then why are you keeping your work so closely guarded?

kevlarman · « **Reply #25 on:** August 18, 2007, 09:32:22 pm »

Quote from: "/dev/humancontroller"

BTW should I file a Q3 enchancement request to bugzilla?

ioquake3 will not break compatibility in any way with idquake3

/dev/humancontroller · « **Reply #26 on:** August 18, 2007, 11:29:37 pm »

Quote from: "benmachine"

Quote from: "/dev/humancontroller"
(your patch is ALMOST good: you forgot to comment out two more)

Where's yours? You must understand that although it's interesting discussing these matters with you it's incredibly frustrating to receive no real input or contributions. It seems like you've already done the hard work but you aren't sharing it. If you don't know how to use diff, then ask. If you do, then why are you keeping your work so closely guarded?

When I posted that long post about how to allow %, I knew that I would be mostly ignored. So I was. "You can take a noob to water, but you can't make a noob drink." So I just brought up the fix, and hoped that one day, one noob will come around. Nope. What now surprized me that you are outstanding from every other noob on this forum, which I appreciate.

I usually hate to ask how to do, I'd rather be a smartass and google it myself. Done, here is my patch, for r755:
http://Mercenariesguild.net/files/982829

Quote from: "kevlarman"

Quote from: "/dev/humancontroller"
BTW should I file a Q3 enchancement request to bugzilla?
ioquake3 will not break compatibility in any way with idquake3

Is ioquake3 even compatible with idquake3 latest release?

khalsa · « **Reply #27 on:** August 19, 2007, 10:28:16 pm »

Next time use http://www.mercenariesguild.net/patches/ insted of /files.

/patches is what you're looking for.

Khalsa

UniqPhoeniX · « **Reply #28 on:** November 25, 2007, 12:38:47 pm »

Yes, Jedi Academy has % enabled. Also @#$&/ and what not.

News:

Author Topic: Allowing the % character in chat (Read 14881 times)

Caveman

tehOen

tehOen

tehOen

Caveman

tehOen