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.
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.
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?
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.
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.
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.
$ 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
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;
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.
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.
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.
p.s.: same should go for all the "x anounces y" where the posted link neither explains what x is nor what y is.