Re: [cobalt-security] New Exploit?

[Martín Fiumara <martinfiumara@xxxxxxxxxxx>]

Hey.... where is te exploit? Y wanted to testit against my raq....
----- Original Message -----
From: "Paul Harvey" <paul@xxxxxxxxxxxxx>
To: <cobalt-security@xxxxxxxxxxxxxxx>; "Cobalt Users List"
<cobalt-users@xxxxxxxxxxxxxxx>
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 [liquid@xxxxxxx])
> * ~~~~~~~
> * exploit for execve/ptrace race condition in Linux kernel up to 2.2.18
> *
> * originally by:
> * (c) 2001 Wojciech Purczynski / cliph / <wp@xxxxxxxxxxxx>
> *
> * improved by:
> * lst [liquid@xxxxxxx]
> *
> * 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 [liquid@xxxxxxx]
> * 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
> cobalt-security@xxxxxxxxxxxxxxx
> http://list.cobalt.com/mailman/listinfo/cobalt-security
>