• Re: Critical Linux exploit in the wild

    From Lusotec@110:300/1.1 to All on Sun May 19 12:40:41 2013
    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA256

    TomB wrote:
    Just a little heads-up...

    Thanks for the warning.

    http://ostatic.com/blog/critical-linux-exploit-in-the-wild

    "If you run servers that provide shell accounts, it’s time to take
    some preventive measures. At least it is if you are running kernel
    versions 2.6.37 to 3.8.8, or if you are running RHEL 6 or a clone like CentOS, then the bug was backported to 2.6.32. I ran the exploit
    myself in a test environment, and it works exactly as expected. Log in
    as a normal user, compile 100 or so lines of C code, run the
    executable and you’ve got a root shell. Scary stuff if you manage
    public shell accounts."

    For the exploit to work, there are a number of conditions that must be
    met:

    * Linux must be compiled with PERF_EVENTS

    This kernel build configuration can be checked with the command
    zgrep PERF_EVENTS /proc/config.gz

    * Shell accounts must have access to a working compiler

    Most servers and desktops systems don't need a compiler installed. As such, and as a policy in my company, such system don't have a compiler or build tools installed. Still, a malicious user or hacker could compile the exploit binary in another system and copy it to the target system.

    Another policy in my company is to mount all user writable partitions with noexec, nosuid, nodev options so even if the exploit binary was placed in
    the system by a user or a hacker (s)he would still have find a way to
    execute the exploit.

    Obviously I checked all my servers where users have shell access, and
    I was pleased to learn that none of my systems were affected :-)

    The exploit can be downloaded here:

    http://packetstormsecurity.com/files/121616/semtex.c

    Some more information on the subject.

    Bug report:
    https://bugzilla.redhat.com/show_bug.cgi?id=962792

    Fix:
    <http://git.kernel.org/cgit/linux/kernel/git/torvalds/ linux.git/commit/?id=8176cced706b5e5d15887584150764894e94e02f>

    Check your systems!

    $ ./semtex
    semtex: semtex.c:51: sheep: Assertion `!close(fd)' failed.

    For some reason it did not work on this system and I think all requirements are present.

    Regards.
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.10 (GNU/Linux)

    iF4EAREIAAYFAlGYrCkACgkQGQjO2ccW76qCQgD/QYoct7HFe6OXM+bJ3CSE3/Yh TqcaKCYfv/QXkTbyAy8A/3nDfHoZ41nvx2DvE99ejWoAKsx2AW6Tnm67ITaSNSSZ
    =O4yG
    -----END PGP SIGNATURE-----


    --- MBSE BBS v0.95.15 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (110:300/1.1@linuxnet)
  • From Casper H.S. Dik@1:0/0 to All on Mon May 20 14:29:13 2013
    Lusotec <nomail@nomail.not> writes:

    Another policy in my company is to mount all user writable partitions with >noexec, nosuid, nodev options so even if the exploit binary was placed in >the system by a user or a hacker (s)he would still have find a way to >execute the exploit.

    Does it work against making the exploit called from the init routine
    in shared object which you could load as LD_PRELOAD in any executable
    you are allowed to run?

    (In Solaris, a shared object in a noexec mount cannot be loaded but
    I'm not sure if Linux extend the noexec to mmap()'ed objects.)

    Of course, if the user has access to perl, python, then noexec doesn't
    help all that much.

    Casper

    --- MBSE BBS v0.95.15 (GNU/Linux-x86_64)
    * Origin: The Kofo BBS MBSE - telnet://fido1.kofobbs.ne
  • From Lusotec@110:300/1.1 to All on Mon May 20 16:18:32 2013
    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA256

    Casper H. S. Dik wrote:
    Lusotec writes:
    Another policy in my company is to mount all user writable partitions with >>noexec, nosuid, nodev options so even if the exploit binary was placed in >>the system by a user or a hacker (s)he would still have find a way to >>execute the exploit.

    Does it work against making the exploit called from the init routine
    in shared object which you could load as LD_PRELOAD in any executable
    you are allowed to run?

    (In Solaris, a shared object in a noexec mount cannot be loaded but
    I'm not sure if Linux extend the noexec to mmap()'ed objects.)

    Of course, if the user has access to perl, python, then noexec doesn't
    help all that much.

    As you can see below, preloading a library from a noexec mounted file system does not work.

    $ PS1=$
    $ LANDUAGE=C
    $ cd ~/tmp
    $ gcc -fPIC -c -o test.o -x c - <<EOF
    #include <stdio.h>
    void _init(void) { printf( "TEST\n" ); }
    EOF
    $ gcc test.o -shared -nostdlib -lgcc -o libtest.so
    $ mount | grep ~/tmp
    none on /home/x/tmp type tmpfs (rw,noexec,nosuid,nodev,size=2g,uid=1000,gid=1000,mode=0700)
    $ LD_PRELOAD=~/tmp/libtest.so uname
    ERROR: ld.so: object '/home/x/tmp/libtest.so' from LD_PRELOAD cannot be preloaded: ignored.
    Linux
    $ su -c "mount -o remount,exec /home/x/tmp"
    Password:
    $ mount | grep ~/tmp
    none on /home/x/tmp type tmpfs (rw,size=2g,uid=1000,gid=1000,mode=0700)
    $ LD_PRELOAD=~/tmp/libtest.so uname
    TEST
    Linux
    $

    Regards
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.10 (GNU/Linux)

    iF4EAREIAAYFAlGaMLgACgkQGQjO2ccW76rIPgD9G0wAV49vDJfiYnBDI/V2ypLg qzomqWcXOBRyQyR7shYA/jTVVRCl2OAaVUsKIWcJUjsALAeO487hYh5eLq2bm8r0
    =5Vnz
    -----END PGP SIGNATURE-----


    --- MBSE BBS v0.95.15 (GNU/Linux-x86_64)
    * Origin: A noiseless patient Spider (110:300/1.1@linuxnet)