Luigi Auriemma

Two things really:

1) There's a nice simple workaround for this, add "tv_enable 1" to your autoexec.cfg, and "tv_disable 0" to your server.cfg. This has the effect of initializing the variable, while still leaving SourceTV disabled. It's not a particularly clean fix, but it prevents the crash which is really all I care about.

2) This seems to be patched in the orange box (DODS/TF2 engine), so it only affects CSS and other Episode1 games. (Valve has a bunch of forks of the source engine, Episode 1 (CSS), Episode 2 (Not sure what multiplayer games use this), Orangebox (TF2/DODS), L4D, and the Dark Messiah code) . It may affect EP2 servers, but I don't know of any mods that run them.

1) yeah I know it, it was also written in the advisory

2) uhmmm how you can say if it's really patched in those other games?
the proof-of-concept I released builds a packet compatible with CSS/HL2 (the base Source dedicated server) while TF2 uses a different type of packet so it's normal that the test fails.
for the maximum clearness of the informations I'm obbligated to perform and base my tests only on the base engine.

tomorrow (well... today) will be release a lot of new vulnerabilities affecting the Source engine so stay tuned.

Anyway I must admit that I'm really surprised from the tests I'm performing, both because the results are excellents and then because all the tests have been performed in an almost blind environment (I don't have the game client) and with a very small effort in the reversing of the protocol (because I wasn't interested in the game), so I'm really positive about them :)

would be good if Valve starts to fix something because there are various old public problems (I have never touched the Source engine before a couple of days ago so I'm sure that there are other public problems of which I'm not aware) and they do absolutely nothing, and this is enough problematic during my tests

yep actually valve still doesn't fix two decent exploited-in-the-wild vulns and those vulns are affecting all source engine game. I can give you those exploits if you want but I don't want to make it into public (such as sending the exploit to milw0rm) and let everyones know it. By the way, they even didn't fix the hell bell bug since ages ...... but that may be fixed recently as I have reported the issue. It works on Windows XP or lower with beep.sys and A2C_PRINT enabled.

By the way I have looked into the leaked source code of HL2 .... as it was flooded on the Internet already ..... the problem may occur at this line in sv_main.cpp .... hopefully valve will fix it soon.

Line 4597 : Q_vsnprintf (string, sizeof( string ), fmt,argptr);

And the function is defined as following :
int Q_vsnprintf( char *pDest, int maxLen, char const *pFormat, va_list params )
{
Assert( maxLen >= 0 );
AssertValidWritePtr( pDest, maxLen );
AssertValidStringPtr( pFormat );
int len = _vsnprintf( pDest, maxLen, pFormat, params );
if( len < 0 )
{
len = maxLen;
pDest[maxLen-1] = 0;
}
return len;
}
By the way I am going to report these stuffs to valve too hopefully they will fix the problem soon with these information. By the way those codes are just used for debug, DO NOT use it for illegal purpose.

I have just released a new advisory in this moment:
http://aluigi.org/adv/sourceupfile-adv.txt

it covers the category of vulnerabilities related the uploading of the files (in my test they work also with sv_allowupload disabled) and the first 2 bugs described there are criticals.

in the next hours I will release a new advisory which for the moment contains at least 2 vulnerabilities but there is still some work to finish with the reversing of some parts of the protocol (which is a chaos) so the number of bugs could raise.

after this I guess I will stop the vulnerability research on the Source engine because it's like hitting a dead man, everything I try to test leads to a security bug so it's useless to continue.
maybe I could try to test some pre-join packets but sincerely at the moment I have lost any interest (which was already near zero) in this.

P.S.: I highly doubt that Valve will do something.
I say this for personal experience (hlbof) and judging what I have read on internet and has been reported on this forum

Sorry for that .... I have found the problematic function already for that format string problem .... it is not located in Q_vsnprintf but inside Sys_Printf() ......... valve uses printf after Q_vsnprintf which causes the problem ...... I am going to make a patch for that .....
void Sys_Printf (char *fmt, ...)
{
va_list argptr;
char text[1024];

va_start (argptr,fmt);
Q_vsnprintf (text, sizeof( text ), fmt, argptr);
va_end (argptr);

if ( developer.GetInt() )
{
#ifdef _WIN32
OutputDebugString( text );
Sleep( 0 );
#endif
}

if ( isDedicated )
{
printf( text );
}
}

no it's not that one.
the vulnerable function is not available in hl2_src, that source code is completely useless because Source uses a completely different protocol (all bitstream based).

the vulnerable function (offset 20168c20 of engine.dll of CSS) should look like the following "guessed" one:

I have to tell you that we have tried to patch Q_vsnprintf but its not related as the server still can be crashed ...... the only possibility is in Sys_Print ....

ehmmm you can't patch a *printf function, you must patch the function which calls the *printf one.

in case you need an example the following assembly instruction simply removes the building of the "reason" string in a quick and easy way:

I'll have a server plugin released that fixes the file upload issue (basically catching any upload requests, and redirecting them to a known-safe directory).. sometime later today.

Edit: Also I've contacted a few people within Valve who typically get shit done, so they may fix this one..

Edit2: released

I have seen that you maintain also a list (http://code.devicenull.org/index.php?title=Misc:HL2_Exploits) of the known public problems affecting the Source engine which seems very useful to known if a problem is already known.

if I'm not in error it doesn't seem to include the commands which cause CPU and resources consumption like dump_globals, sv_soundemitter_flush, sv_soundemitter_filecheck, sv_findsoundname, sv_soundscape_printdebuginfo and rr_reloadresponsesystems or are they indexed with a different name/description?

then about the A2C_PRINT thing, it can be defined as a bug only in two occasions which probably Valve didn't consider:
- flooding with spoofed IP address (because the engine blocks those from the same after a certain number)
- the usage of the bell char (0x07) if the server runs in console mode (the most used mode) and with the beep service active (default)

anyway the bell bug or the generic "spamming" on the console can be exploited also in tons of other ways, so for the bell problem the only way is to disable the useless beep service: sc config beep start= disabled

I'd say the spammy commands would fall under http://code.devicenull.org/index.php?ti ... mmand_spam .. I try to avoid giving people enough information to exploit the issues if I can avoid it. The more clever people could figure it out from the information there probably, but I'm trying to avoid people that would just come along and copy and paste stuff.

as promised I have just released the new (and probably the conclusive one of this testing session) advisory, again a critical vulnerability which "could" lead to code execution:

http://aluigi.org/adv/sourcefraghof-adv.txt

I have decided to not include the other vulnerability I found because was only a temporary freeze so not a serious security vulnerability, although dangerous.

During my tests I performed also a quick check of the download function.
The test was complete and I can say that it's ok so nothing to worry but there are 2 things which I don't like much:

1) is possible to specify files in the root of the disk simply placing a backslash at the beginning so if the server is located on c:\srcds it's enough to specify "\config.sys" to reach the file c:\config.sys which makes enough useless the check of the ".." string to avoid the directory traversal vulnerabilities

2) there are no limits to the number of files that the user can download simultaneously from the server keeping them opened, indeed in my test I obligated my server to keep thousands of file handles for almost each file in the cstrike folder, anyway this operation had no negative effects on the server so it's not important

that's all for the moment.

in case someone is interested to protocols and technical stuff I have just made a small cleanup of the sourcefs and sourcenotvnull proof-of-concepts:
- in the first has been removed the sending of the cl variables (which was totally useless for the testing of the bug)
- in the second has been figured the protocol so now it's visible just the one_bit which says that the client is a SourceTV client (imho interesting)

Would you be able to test if this work on the OrangeBox/TF2 engine, or could you make the packet compatible with it?
I would like to know if this has been fixed or not.

yes also the latest 3933 build used in these games is affected by the bugs, I'm testing the protocol and the vulnerabilities just in this moment (practically the only difference is a crc16 value in the packet).
I'm going to update the advisories and the proof-of-concepts after some more tests.

ok all the stuff has been updated.
ALL the vulnerabilities affect the 3933 build except the SourceTV one (which was also the less critical bug that I found in this session).

About the proof-of-concepts I have update only the proxocket/sudppipe plugins because more easy to update and simpler to use for verifying the vulnerabilities (I guess that each admin has a client of these games, right?).

remember that there is no easy_to_recognize difference between the packets used in TF2 and those used in HL2/CSS (otherwise should be needed to calculate the crc of the whole packet and comparing it with the current one, enough easy to do but too much for a proof-of-concept) except that the first one seems to use the LZSS compression so I have based the instruction which "switches" the 2 protocols (that simple crc16 I talked before) just on this compressed packet.

so if, for some unkown reason, your client doesn't send a compressed first packet it will be handled as a CSS/HL2 one, in which case tell me and I will implemented also the other "crc-check" way explained before.

seems that Valve has released a new build for TF2/orangebox/L4D some hours ago:
build 3939

links to the news:
http://store.steampowered.com/news/2759/
http://store.steampowered.com/news/2760/

in the changelog is written that it fixes all the vulnerabilities I reported in my advisory, included the sourcetv bug that wasn't confirmed here in build 3933.
I have just tested this new build and yes, I can confirm it although the file bug has not been tested correctly because has been added an additional check which doesn't allow my proof-of-concept to reach the desired function.

so, from what I can understand, Valve will no longer support Counter Strike Source and Half-Life 2.
these 2 games can be considered dead, obsolute, no longer supported for some unkown reasons (after all it should be only the update of the base engine... mah).

well I will keep in mind it so that if in future (I highly doubt) I will do another research session like the one of the previous days I will focus entirely on the TF2 build that can be considered the most recent and updated version of the Source engine, and so the only one to test.

I fail to understand VALVe's logic in not providing support to their most popular game.

By SourceMod's Stats count, Counter-Strike: Source servers are in excess of 30,000. The highest number for any game to even come close to it is Left 4 Dead with just a mere 6,751 servers.

I guess VALVe is hoping open source projects such as my own Kigen's Anti-Cheat or RCON Locker/Exploit Fix would provide all the fixes for all these exploits that are deeply embedded in the engine.

I mean my plugin's goal was just to cover a few exploitable commands and for the most part beat the ever lovin' crap outta cheaters. Now I can't do that properly because VALVe keeps expecting third party plugins to fix all their damn issues. I mean if they want us to fix their engine they might as well pay us something for it.

I'm not sure if I understood what you are saying. Did you say that they didn't fix the file uploading correctly and it is still possible?

I meant that I wasn't able to verify that the bug was really patched.
practically in my proof-of-concept the protocol for reaching the "upload" function was a bit work-arounded because I needed to add an useless fragment to the packet otherwise I wasn't able to reach the function and now that have been introduced major restrictions on these fragments (related to the sourcefraghof vulnerability) the testing packet used for the file uploading bugs is rejected.

anyway I have performed the complete test just in this moment and there is still a type of vulnerability active.
the arbitrary files uploading and files deletion are gone, so ok.
BUT is still possible to write files from the root path although limited by the file name:

this was even an example I showed in my advisory ("\file.txt").

*edit*: ok the files are limited by their extensions so there is no security risk, now I perform another quick test and if there are updates I will post them here

full test performed, I have found no ways to bypass the check on the extension so it can be declared not a problem

Every time I try now, I get this in my server console:

Malformed fragment ofs 0 len 0, buffer size 0 from xxx.xxx.xxx.xxx:xxxxx

Could you upload the new proxocket.dll which fixes the fragment problem?

Do you know what are the list of allowed extensions now?

no at the moment I don't know how to replicate the sourceupfile problem without using the fragmented part of the packet, and sincerely it's also enough useless now since the bugs have been fixed and already confirmed by me that they have been fixed so there is no reason for me to spend other time on this thing.

anyway if you want to make a test at any cost remove the fragment check from the TF2 server build 3939 with ollydbg, from:
to:

tada': http://store.steampowered.com/news/2765/

important udpate.
I needed to check this thing the 21 August but I said "I will do it tomorrow" and so I did it only today.

the file deletion bug is NOT fixed.
I repeat, the game is STILL VULNERABLE.

the *insert_any_incompetence_adjective* at Valve who have written the code have simply disallowed the files with a slash/backslash at the end but this is stupid because this wasn't the bug but was only a quick test I specified in my advisory.
indeed the bug is in the fact that the Source engine creates the full paths of the specified files so if you use "cfg\server.cfg\hello.txt" you will delete the file cfg\server.cfg.

that's boring because everytime I need to be detailed even on things that are so obvious (or at least they were for me, so imagine if they weren't clear for who created that code)... very boring

P.S.: no you can't test the bug with the old proof-of-concept because it used a work-around that has been removed by Valve while fixing the fragments vulnerability

Will you release a new proof of concept?

no