Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.security > #280 > unrolled thread

Re: Critical Linux exploit in the wild

Back to article view | Back to comp.os.linux.security

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Critical Linux exploit in the wild Lusotec <nomail@nomail.not> - 2013-05-19 11:40 +0100
    Re: Critical Linux exploit in the wild Casper H.S. Dik <Casper.Dik@OrSPaMcle.COM> - 2013-05-20 12:29 +0000
      Re: Critical Linux exploit in the wild Lusotec <nomail@nomail.not> - 2013-05-20 15:18 +0100

#280 — Re: Critical Linux exploit in the wild

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

[toc] | [next] | [standalone]

#281

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

[toc] | [prev] | [next] | [standalone]

#282

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

[toc] | [prev] | [standalone]

Back to top | Article view | comp.os.linux.security

csiph-web