Hi everyone, thanks a lot to frank and bernhard for investigating this problem. I wasn't able to reproduce their results at first, even though my server was running in sv_lan (my usual test-settings). After running the exploit on a windows-machine, I were able to crash my server, too - running the exploit on the linux box didn't affect the server. I'm still unsure if this is caused by my network-configuration, or if the precompiled windows binary behaves a little bit different from the linux version.
Anyway, I was able to track the problem far more towards it's root, and the new patch I made should prevent the buffer-overrun announced on wednesday as well as the freeze-bug against non-Won servers found by Luigi and Delikon back in april (see luigis page). In all my tests, with sv_lan enabled and disabled, running the exploit on the same machine and on a remote one, on linux and on windows, and with hl-headnut and hlfreeze exploits, the server didn't crash anymore. I suggest anyone running a 3.1.1.0 server to either install the new version of the patch or to upgrade to valve's new 3.1.1.1d server. The new patch _should_ fix all known problems, but here known means "I know about". I give no warranty, and valve won't give support for it. It's only improvement over a 3.1.1.1d upgrade is that it allows you to use your stable and not that performance-demanding 3.1.1.0 server. The one thing that still works is the non-Won server fake-player exploit, that fills your lan-servers so noone can join (luigis page, too), but this one also works on 3.1.1.1d. Those of you who actually tried the fill-exploit against a 3.1.1.1d server and disagree with me should just remove the "password" line from the exploits-source, or set their server password-protected and enter the pass in the exploit - it still works. This is because the new hlds-beta makes sure that every /parameter is followed by a /value (/param/value/param/value/) in the connect-infostring, so if either the password is missing at all or if there is actually a password given, the exploit will fill the server. To be fair, this is something not really easy to fix, at least not without changing the whole connect procedure (from what i saw over the last days). If there's someone with an idea I'd happily put it in the patch, too. Again, I'm looking for someone to host the files (4.9kb tar.gz), so if you got a server and the time to put it up tell me by mail. Meanwhile, you can find it at http://mmd.ath.cx/boffix.tar.gz Installation Instructions: - copy the boffix_i386.so to your hlds_l directory - modify your hlds_run script so it contains the line "export LD_PRELOAD=./boffix_i386.so" Linux-Serveradmins should put that line right before or after the LD_LIBRARY_PATH export, while FreeBSD admins need to put it before the two lines containing "$HL $*", so the fix only get's loaded for the hl-executable and not for system utilities invoked by the script. If the fix is loaded correctly it displays a line: "boffix_i386.so - v2 - successfully loaded and hooks installed" Kind regards, Dominic (Virtual Master) ------------------ [EMAIL PROTECTED] On Sun, 3 Aug 2003, Frank Stollar wrote: > Frank Stollar wrote: > > Hi, > > > >>>> I have no idea how this can happen to a server - if the patch got > >>>> loaded > >>>> it prevents anything beyond 255 characters from being passed to the > >>>> original function. > >>> > >>> > >>> I'm guessing, since no one else is reporting crashes/hangs/overflows, > >>> that this isnt related to your patch. Frank, are you sure beyond a > >>> doubt? If the patch wasnt working, or was crashing servers, don't you > >>> think we would see more comments here? I *know* attacks stopped against > >>> my servers once i applied the patch. > >> > >> > >> > >> We have over a dozen servers using that patch on 3.1.1.0.c, all were > >> tested > >> after patching and none have went down since it was applied. I think > >> Frank > >> is doing something wrong. Watch your server output when you fire it up > >> Frank, I forgot to put the .so file in the hlds_l dir on one of the > >> servers > >> I upgraded but caught the mistake when I saw it looking for the file on > >> startup. > > > > > > Thank you for your answers. We are investigating further into it and > > will retry this test. > > Ok here we go. We just found the problem and it is persistent, but not > as bad as supposed first. > We tested it again at our LAN server and he was vulnerable again after 2 > attacks. Ok, switching over to inet via 'sv_lan 0' and it works > fluently. Hammered on the server with the exploit-tool but it was not > going down. Switched back to lan with 'sv_lan 1' and after 2 attacks it > goes to it knees. > > That would be no big problem for most of you, but I'm running LAN > servers too, and I don't want it to be killed by a kiddy during a > tournament or similiar. > Therefor when the server is running in LAN mode, another function seems > to be responsible for the exploit. > > I hope Dominic would take a look into this problem and could fix it. > > Thx go to Bernhard again for his help. > > cheers > Frank > > _______________________________________________ > To unsubscribe, edit your list preferences, or view the list archives, please visit: > http://list.valvesoftware.com/mailman/listinfo/hlds_linux > _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
