At 01:25 AM 12/11/2001, you wrote: >I got hacked using the exploit below. Are Cobalts supposed to be >protected against this? > >I use SSH2 and have patches in place. They seem to have got into root via >one of our users. > >Does anyone know what version of Linux is used on the Raq4? >
a modified version of RedHat 6.2 - according to www.netcraft.com Apache/1.3.20 Sun Cobalt (Unix) mod_ssl/2.8.4 >---------------------------------------------- >/* >* epcs2 (improved by lst [[EMAIL PROTECTED]]) >* ~~~~~~~ >* exploit for execve/ptrace race condition in Linux kernel up to 2.2.18 >* >* originally by: >* (c) 2001 Wojciech Purczynski / cliph / <[EMAIL PROTECTED]> >* >* improved by: >* lst [[EMAIL PROTECTED]] >* >* This sploit does _not_ use brute force. It does not need that. >* It does only one attemt to sploit the race condition in execve. >* Parent process waits for a context-switch that occur after >* child task sleep in execve. >* >* It should work even on openwall-patched kernels (I haven't tested it). >* >* Compile it: >* cc epcs.c -o epcs >* Usage: >* ./epcs [victim] >* >* It gives instant root shell with any of a suid binaries. >* >* If it does not work, try use some methods to ensure that execve >* would sleep while loading binary file into memory, >* >* i.e.: cat /usr/lib/* >/dev/null 2>&1 >* >* Tested on RH 7.0 and RH 6.2 / 2.2.14 / 2.2.18 / 2.2.18ow4 >* This exploit does not work on 2.4.x because kernel won't set suid >* privileges if user ptraces a binary. >* But it is still exploitable on these kernels. >* >* Thanks to Bulba (he made me to take a look at this bug ;) ) >* Greetings to SigSegv team. >* >* -- d00t >* improved by lst [[EMAIL PROTECTED]] >* props to kevin for most of the work >* >* now works on stack non-exec systems with some neat trickery for the >automated >* method, ie. no need to find the bss segment via objdump >* >* particularly it now rewrites the code instruction sets in the >* dynamic linker _start segment and continues execution from there. >* >* an aside, due to the fact that the code self-modified, it wouldnt work >* quite correctly on a stack non-exec system without playing directly with >* the bss segment (ie no regs.eip = regs.esp change). this is much more >* automated. however, do note that the previous version did not trigger >stack >* non-exec warnings due to how it was operating. note that the regs.eip = >regs.esp >* method will break on stack non-exec systems. >* >* as always.. enjoy. >* >*/ > > >---------------------------------------------------------------------------- >--- _______________________________________________ cobalt-security mailing list [EMAIL PROTECTED] http://list.cobalt.com/mailman/listinfo/cobalt-security
