Re: Critical Linux exploit in the wild

[Lusotec]

-----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-----

[Casper H.S. Dik]

Lusotec <nom...@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

[Lusotec]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Casper H. S. Dik wrote:

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-----