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;
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.
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.
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.
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?
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.
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.
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.
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.
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.
$ 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
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.
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.
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.
He assumes the system will have an executable named "bash".
As this 0day is written, rename bash to sh and it will fail. Better yet, remove bash from your system and replace it with a simpler POSIX compliant sh.
No respectable systemwide shell script should rely on bash anyway.
99 comments
[ 2.2 ms ] story [ 167 ms ] threadKernel 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/
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
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.
$ 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;
p.s.: same should go for all the "x anounces y" where the posted link neither explains what x is nor what y is.
umm NSFW, if you work at a school.
That's the difference between a power user and a hacker.
A power user RTFM, a hacker RTFS.
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.
(from below)
Joy unconfined.
Whether the vulnerability is patched or the exploit just doesn't work, I can't say, but I get this:
(Don't worry the hostname is oneiric64. It's not running oneiric.)Want me to pastebin it? edit:
It starts out
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.
Lack of exploit code doesn't imply a lack of vulnerability :)
I may be wrong though, as I didn't scan through all the affected code.
IGjDf1e4eQxWyBFArYM8HgvCuns6p+GbfHoE3SPxYV59kXnA12BWdMr6D5eAAFgtBSX+/Yi+vLxMmEiszkwHLCA=
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):
* 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.
* 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
[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
./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 ...
Compile like this and it works:
[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@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:~$
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
$ 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
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
NSFW http://fucksheep.org/~sd/mspaint/
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.
https://security-tracker.debian.org/tracker/CVE-2013-2094
As this 0day is written, rename bash to sh and it will fail. Better yet, remove bash from your system and replace it with a simpler POSIX compliant sh.
No respectable systemwide shell script should rely on bash anyway.