Hey.... where is te exploit? Y wanted to testit against my raq.... ----- Original Message ----- From: "Paul Harvey" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; "Cobalt Users List" <[EMAIL PROTECTED]> Sent: Tuesday, December 11, 2001 4:25 AM Subject: [cobalt-security] New Exploit?
> 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? > > > ---------------------------------------------- > /* > * 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 > _______________________________________________ cobalt-security mailing list [EMAIL PROTECTED] http://list.cobalt.com/mailman/listinfo/cobalt-security
