Linux local privilege escalation 0day, 2.6.37 - 3.8.10 | Hacker News Reader

Linux local privilege escalation 0day, 2.6.37 - 3.8.10

fucksheep.org

140 pointsezdiy92 comments

Can we please stop posts like that without a proper introduction? I'm counting myself as proficient in Linux for many years and all i get is that it's some C code and apparently some 0day. What? I'm certainly not starting to decipher that or compile and run it.

p.s.: same should go for all the "x anounces y" where the posted link neither explains what x is nor what y is.

I wish HN would allow both text and links in the same article. Otherwise you basically have to write a blog entry.

HN encourages you to write a blog post and submit that, yes.

I believe rdl wants HN to be their blog.

HN hates "blogspam", so I'd be reluctant to write a 1-3 para intro and then cite a post like this, then submit it to HN. Although I guess if it added context, it wouldn't be horrible.

If you haven't got enough to say that would raise a blog post above being blogspam, then submit your thoughts as a comment after submitting the link.

I'm sure that's nearly impossible to manage in this day and age. If only someone could create a service that made such a thing easy.

You can simply post a comment to your own submitted story.

Minimal explanation (allegedly by author "sd") at: http://packetstormsecurity.com/files/121616/semtex.c

I would have loved to have THIS as the link target, the three short sentences make a big difference, imo.

Maybe they drew a picture to explain it, http://fucksheep.org/~sd/mspaint/

umm NSFW, if you work at a school.

Who the F keeps a directory of images like this? I've seen enough internet for the day.

> I'm counting myself as proficient in Linux for many years

That's the difference between a power user and a hacker.

A power user RTFM, a hacker RTFS.

The problem is you might be a Windows/Java/ASM/Lisp hacker, and you would be able to understand the general principles, but not the specific (and unfamiliar) source code.

I think the problem is that the comment appears to use a "no true Scotsman" fallacy.

When you imply that a hacker should read and understand the source, are you referring to the posted code or Linux itself (or both)?

The difference is that i don't know if this is worthy to invest time and effort or not. Does this have an impact on a wide install base of servers? Apparently some HNers can't reproduce this. So it's not worth my time? I would assume it's just common sense (or courtesy) to put a little bit of text around it. How often do you read a news article about quantum mechanics that is just some lines of advanced math without any explanation at all?

Well, to be fair it's rather easy to spot what this is doing. Looking at the last two lines of code:

    assert(!setuid(0));
    return execl("/bin/bash", "-sh", NULL);

It spawns a root shell, so it's (probably) a (local) privilege escalation.

That doesn't explain anything about how it works though.

Anybody could submit some unreadable C code that finishes up with setuid(0) and exec("/bin/sh") - it isn't interesting without an explanation of what it's doing.

Well, that's a different question. A fully fledged analysis of this exploit would certainly be interesting. But it's an 0day, I think it's more important to patch vulnerable servers first. And I don't see what's stopping anyone from submitting an analysis of this a few days later.

Silent patched a while ago:

Kernel must be compiled with PERF_EVENTS (default on most modern distros). Bug fixed in 3.8.10.

This is the kill log:

http://lkml.indiana.edu/hypermail/linux/kernel/1304.1/04302....

This bug got apparently backported from 2.6.37 into centos6 2.6.32 kernels.

patch here: https://patchwork.kernel.org/patch/2441281/

The patch looks like it's present in 3.8.9 also, correct? (someone double-check)

You're correct.

Bug is in 2.6.37-3.8.8, fixed in 3.8.9.

http://lxr.linux.no/linux+v3.8.9/kernel/events/core.c#L5331

Spender did excellent write-up about how it exactly works: http://www.reddit.com/r/netsec/comments/1eb9iw/sdfucksheepor...

Tested the exploit on CentOS:

Linux 2.6.32-358.6.1.el6.x86_64 #1 SMP Tue Apr 23 19:29:00 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux (latest CentOS kernel):

  [user@centos ~]$ gcc -O2 exploit.c 
  [user@centos ~]$ ./a.out 
  2.6.37-3.x x86_64
  sd@fucksheep.org 2010
  -sh-4.1#

I tested on two Ubuntu systems:

* Linux beqbrgbrg1ux006.tpvision.com 3.2.0-29-generic #46-Ubuntu SMP Fri Jul 27 17:03:23 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

* Linux DrinkCoffee 3.5.0-25-generic #38-Ubuntu SMP Mon Feb 18 23:27:42 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

And the process gets killed because of a kernel oops in both.

Same on Ubuntu 13.04 w/ 3.8.0-19-generic.

Kernel panic on Ubuntu 12.04

* Linux bk-ak 3.2.0-40-generic #64-Ubuntu SMP Mon Mar 25 21:22:10 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

Tested on Arch Linux x64: [test@libros-dev tmp]$ uname -a Linux libros-dev 3.8.5-1-ARCH #1 SMP PREEMPT Fri Mar 29 19:18:14 CET 2013 x86_64 GNU/Linux

[test@libros-dev tmp]$ ./a.out

Killed

This is in dmesg:

[2112052.363397] Oops: 0000 [#1] PREEMPT SMP

[2112052.363890] CPU 0

[2112052.363969] Pid: 3775, comm: a.out Not tainted 3.8.5-1-ARCH #1 innotek GmbH VirtualBox/VirtualBox

It's a great day to have kmod-tpe[1] installed. Having said that, after I rmmod-ed tpe the exploit still failed (I'm on 2.6.32-358.6.1.el6.x86_64):

./semtex 2.6.37-3.x x86_64 sd@fucksheep.org 2010 semtex: semtex.c:81: main: Assertion `p = memmem(code, 1024, &needle, 8)' failed. Aborted

[1] - http://elrepo.org/tiki/kmod-tpe

LE: exploit needs to be compiled with -O2 flags to work ...

You get this error when you compile the exploit incorrectly.

Compile like this and it works:

  gcc -O2 semtex.c && ./a.out

Didn't work

[user@host ~]$ uname -a Linux host.company.com 3.8.11-200.fc18.x86_64 #1 SMP Wed May 1 19:44:27 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux [user@host ~]$ gcc -O2 semtex.c && ./a.out a.out: semtex.c:51: sheep: Assertion `!close(fd)' failed. Aborted (core dumped)

Me too, didn't work:

me@myServer:~$ uname -a Linux KALIDHCP 2.6.32-5-amd64 #1 SMP Mon Feb 25 00:26:11 UTC 2013 x86_64 GNU/Linux me@myServer:~$ cat /etc/debian_version 6.0.7 me@myServer:~$ gcc -O2 semtex.c me@myServer:~$ ./a.out a.out: semtex.c:51: sheep: Assertion `!close(fd)' failed. Aborted me@myServer:~$

Wait, so let me get this right: This is a Linux local privilege escalation 0day that works on (most) kernels ver. 2.6.37 to 3.8.10?

Well... [2.6.37, 3.8.10) -- non-inclusive on the upper bound.

Fixed in 3.8.10 so that one's good.

Otherwise, yes, yes it is.

*Edit: Actually it looks like it's fixed in 3.8.9 (made it in 3.8.9rc8) based on the patch at: https://patchwork.kernel.org/patch/2441281/ -- Someone with more knowledge of kernel dev should double-check.

And the bug was apparently backported to 2.6.32 on CentOS.

Joy. This is going to be a big issue if the major distributions don't have a fixed kernel out in the next day or so (and then lazy admins don't remember to install it).

I would guess anyone with an active php shell they haven't discovered before is going to have a Bad Time.

Also, for any Redhat/CentOS users, here is bugzilla for this issue https://bugzilla.redhat.com/show_bug.cgi?id=962792

For those running Debian:

https://security-tracker.debian.org/tracker/CVE-2013-2094

Works on Debian stable (wheezy).

Joy unconfined.

I have an ubuntu precise that has been keeping up with kernel updates, running 3.2.0-41-generic, and it does not give root.

Whether the vulnerability is patched or the exploit just doesn't work, I can't say, but I get this:

  yebyen@oneiric64:~$ gcc -O2 semtex.c 
  yebyen@oneiric64:~$ ./a.out 
  Killed

(Don't worry the hostname is oneiric64. It's not running oneiric.)

Try dmesg.

I checked dmesg. It's clear that something bad happened, but I didn't get root. I don't really know what I'm looking at, I just ran arbitrary code on my least valuable machine trying to learn something.

Want me to pastebin it? edit:

It starts out

  [318258.327110] BUG: unable to handle kernel paging request at 0000001781ef7788
  [318258.328251] IP: [<ffffffff8108f1a5>] atomic_dec_and_mutex_lock+0x15/0x90
  [318258.328251] PGD 2b18b067 PUD 0 
  [318258.328251] Oops: 0000 [#4] SMP

Same here:

  Linux (redacted) 3.2.0-41-virtual #66-Ubuntu SMP Thu Apr 25 03:47:17 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

  [  413.309308] BUG: unable to handle kernel paging request at 0000001781eef4e8
  [  413.310359] IP: [<ffffffff8108d605>] atomic_dec_and_mutex_lock+0x15/0xa0
  [  413.311025] PGD 1c4ec067 PUD 0 
  [  413.311680] Oops: 0000 [#6] SMP 
  [  413.312007] CPU 0

Edit: disregard the timestamp above, VM has not synced with NTP for some time.

So, the question is, are we safe this time? Or do we just need a better exploit code to be written for us? :)

just need better exploit code

citation needed

Frankly, I have to apologize I've never bothered with testing on ubuntu. That niche (workstations and small servers) is different beast for somebody else to bite.

For what it's worth, this causes my 3.2.29 64-bit Slack box to kernel panic. At least they can't do anything once they root it :>

3.4.2-x86_64-linode25 doesn't seem to suffer from this.

    gunther> gcc -O2 semtex.c
    gunther> ./a.out
    a.out: semtex.c:63: main: Assertion `(map = mmap((void*)0x380000000, 0x010000000, 3, 0x32, 0,0)) == (void*)0x380000000' failed.
    Aborted
    gunther> uname -r
    3.4.2-x86_64-linode25

3.5.2-linode45 also seems unaffected

$ uname -a Linux li252-14 3.5.2-linode45 #1 SMP Wed Aug 15 14:10:55 EDT 2012 i686 i686 i386 GNU/Linux

$ gcc -O2 semtex.c && ./a.out semtex.c: In function âfuckâ: semtex.c:30:37: warning: cast from pointer to integer of different size semtex.c:30:23: warning: cast to pointer from integer of different size semtex.c:31:21: warning: cast from pointer to integer of different size semtex.c:37:19: warning: cast to pointer from integer of different size semtex.c: In function âmainâ: semtex.c:74:3: warning: cast to pointer from integer of different size semtex.c:74:3: warning: cast to pointer from integer of different size a.out: semtex.c:51: sheep: Assertion `!close(fd)' failed. Aborted

CVE-2013-2094

The debian security tracker claims squeeze is not vulnerable, so that's something... https://security-tracker.debian.org/tracker/CVE-2013-2094

Ubuntu's bug: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1179943

Is there a CVE for this one?

Not that I know of, hence 0day.

Not that I can see.

CVE-2013-2094

(from below)

Hm, doubtful.

PS1/ $ w

12:17:27 up 38 days, 17:18, 1 user, load average: 0.44, 0.11, 0.04

USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT

user pts/0 Narnia 07:11 0.00s 0.25s 0.11s w

PS1/ $ uname -a

Linux Rivendell 2.6.32-358.2.1.el6.x86_64 #1 SMP Wed Mar 13 00:26:49 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

PS1/ $ cat /etc/redhat\-release

CentOS release 6.4 (Final)

PS1/ $ ./a.out

2.6.37-3.x x86_64

sd@fucksheep.org 2010

a.out: sheep.c:81: main: Assertion `p = memmem(code, 1024, &needle, 8)' failed.

Abort(coredump)

PS1/

Seems it is nicely dumped instead of doing weird things in userland.

Under root is doesn't coredump, but returns to the prompt without any hassle.

Either your kernel is patched, or the exploit does not work on your system. It certainly fails without -O2, glance over the code indicates horrible reliance on various UB on how gcc compiles it.

$ grep -A 10 'int perf_swevent_init' linux-2.6.32-358.el6/kernel/events/core.c static int perf_swevent_init(struct perf_event *event) { int event_id = event->attr.config;

if (event->attr.type != PERF_TYPE_SOFTWARE) return -ENOENT;

switch (event_id) { case PERF_COUNT_SW_CPU_CLOCK: case PERF_COUNT_SW_TASK_CLOCK: return -ENOENT;

You get this error when you compile the exploit incorrectly. Compile like this and it works:

  gcc -O2 sheep.c && ./a.out

Testing this on various boxen I have immediate access to with kernel versions from 3.2, 3.5, 3.7 and 3.8, I get mixed results. On half of them it triggers a kernel bug, but gets killed before it can return a root shell, on the others it aborts without triggering a kernel bug. Either I'm rather lucky or this exploit is fragile. Perhaps both.

His naming conventions are splendid.

New Zealand represent.

RedHat has a SystemTap fix available on their bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=962792#c13

on a somewhat related topic, the author of this has some issues he/she needs to work out.

NSFW http://fucksheep.org/~sd/mspaint/

Strange that the owner of fucksheep.org would be a bit of a deviant.

Alpine 2.4, 2.5 and 2.6 are not vulnerable even though PERF_EVENTS is enabled:

    [5126545.172128] BUG: unable to handle kernel paging request at ffffffff1de68048

Why the hell is CONFIG_PERF enabled in distribution kernels?? A normal server/desktop user would NEVER USE THAT. If you're smart enough to use Perf, you ought to be smart enough to compile your own kernel.

This is a brilliant example of how stupid many distros are with their kernel configurations. They need to start understanding that enabling features that nobody uses only increases the probability of problematic bugs.

Also, they need to stop enabling CONFIG_CC_STACKPROTECTOR. It slows stuff down, and as can be seen here, often doesn't do any good.

Does this work against grsec kernel?

It works unless you have active kernel exploit protection on, which kills all processes by any user causing "suspicious kernel crash" until reboot.

no luck in centos 6.4 i686

[a@err ~]$ uname -a Linux err 2.6.32-358.6.1.el6.i686 #1 SMP Tue Apr 23 18:13:20 UTC 2013 i686 i686 i386 GNU/Linux [a@err ~]$ ./a.out a.out: 1.c:51: sheep: Assertion `!close(fd)' failed. Aborted (core dumped) [a@err ~]$

Works in latest RHEL6.4 latest available kernel 2.6.32-358.6.1.el6.x86_64

Does that work on a Hardened Gentoo Kernel too? 3.8.10

[NSFW Warning] hahahhahaha oh man.. that guy has a really funny pubertal pervert humor.. you shouldn't check the other folders on that server.

[NSFW] is this guy a kid? http://fucksheep.org/~sd/mspaint/

Edit: It does work on CentOS 6.3

Also works on CentOS 6.4.

Linux XX 2.6.32-358.2.1.el6.x86_64 #1 SMP Wed Mar 13 00:26:49 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

the link to fucksheep.org is now marked as malicious by firefox lol

Just from looking at the code, this exploit works only for 32 bit machines, all 64 bit installations should be fine.

Can you back that up? The exploit states x86_64, and even if there is only an x86 exploit published, it's likely the same vulnerability is present on an x86_64 kernel (in general).

Lack of exploit code doesn't imply a lack of vulnerability :)

I mean, the fix consists in making sure that attr.config has all the 64 bits cleared - on the 64 bit machines, int is 64bit, so u64 == int, and all the bits are correctly handled. on 32 bit machines, int is 32bit, and the top 32 bit of attr.config is not cleared.

I may be wrong though, as I didn't scan through all the affected code.

I just tried it on a 64bit machine and it works.

I just ran the exploit on a 64bit machine and it worked as expected, I got root privileges.

It's not that hard to port it to 32 bits, just hang on week or two. I'm just too lazy.

IGjDf1e4eQxWyBFArYM8HgvCuns6p+GbfHoE3SPxYV59kXnA12BWdMr6D5eAAFgtBSX+/Yi+vLxMmEiszkwHLCA=

Hahaha. Love that you signed your message with your 'jewgold' address. Nice 0day.

Me too. I love latent antisemitism.

The goto and labels stick out like coal in a pile of gold.

Duly noted. Will attempt to obfuscate using longjmp next time.

No, int is the same size on 32-bit and 64-bit Linux: sizeof(int) == 4 sizeof(long) == 4 (32-bit), 8 (64-bit) sizeof(long long) == 8

I learn something every day, thank you !

http://en.wikipedia.org/wiki/64-bit_computing#64-bit_data_mo...

Wrong -- works on x86_64 Debian.

Reply on news.ycombinator.com