10 ms·

Hole in Linux kernel provides root rights

69 points by spahl 16y ago

bustamove 16y ago
just tried the exploit on my slicehost box and it successfully root it!
bustamove 16y ago
~# uname -a Linux slice 2.6.32.12-rscloud #26 SMP Mon May 17 12:35:34 UTC 2010 x86_64 GNU/Linux
jsean 16y ago
How come Robert sucks? edit: ok, if you didn't notice source's filename; http://sota.gen.nz/compat2/robert_you_suck.c http://sota.gen.nz/compat2/robert_you_suck.c And just in case... also ;)
- psiconaut 16y ago
  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.
- blasdel 16y ago
  There's a tradition of ridiculous file names for these things, like jessica_biel_naked_in_my_bed.c
  - viraptor 16y ago
    Both file names and nicks really - Przemysław Frasunek listed in the code is (was?) also known as "babcia padlina" (grandma carrion)
    - jacquesm 16y ago
      Dobrze rozumiec :)
- leif 16y ago
  From that file, this guy http://swiecki.net/index.html 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).
jacquesm 16y ago
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?
- viraptor 16y ago
  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.
  - jacquesm 16y ago
    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 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 ;)
    - viraptor 16y ago
      My faviourite is probably the last openssh 0day "exploit": http://antihackerlink.or.id/0day-for-openssh-0pen0wn-is-spreaded.html http://antihackerlink.or.id/0day-for-openssh-0pen0wn-is-spre... See what happens with the "fremote(jmpcode)" function in 'main()'.
      - jacquesm 16y ago
rbanffy 16y ago
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?
- mfukar 16y ago
  How would you go about testing system calls?
  - rbanffy 16y ago
    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.
    - mfukar 16y ago
      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-hidden-in-linux-closet.html http://theinvisiblethings.blogspot.com/2010/08/skeletons-hid... [2] http://grsecurity.net/~spender/64bit_dos.c http://grsecurity.net/~spender/64bit_dos.c
      - deleted 16y ago
        [deleted]
jrockway 16y ago
Incidentally, there are several buffer overflow errors in the exploit code.
- amackera 16y ago
  Exploits for the exploits?

69 points by spahl 16y ago

bustamove 16y ago

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

bustamove 16y ago

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

jsean 16y ago

How come Robert sucks? edit: ok, if you didn't notice source's filename; http://sota.gen.nz/compat2/robert_you_suck.c http://sota.gen.nz/compat2/robert_you_suck.c And just in case... also ;)

psiconaut 16y ago
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.
blasdel 16y ago
There's a tradition of ridiculous file names for these things, like jessica_biel_naked_in_my_bed.c
- viraptor 16y ago
  Both file names and nicks really - Przemysław Frasunek listed in the code is (was?) also known as "babcia padlina" (grandma carrion)
  - jacquesm 16y ago
    Dobrze rozumiec :)
leif 16y ago
From that file, this guy http://swiecki.net/index.html 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).

jacquesm 16y ago

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?

viraptor 16y ago
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.
- jacquesm 16y ago
  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 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 ;)
  - viraptor 16y ago
    My faviourite is probably the last openssh 0day "exploit": http://antihackerlink.or.id/0day-for-openssh-0pen0wn-is-spreaded.html http://antihackerlink.or.id/0day-for-openssh-0pen0wn-is-spre... See what happens with the "fremote(jmpcode)" function in 'main()'.
    - jacquesm 16y ago

rbanffy 16y ago

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?

mfukar 16y ago
How would you go about testing system calls?
- rbanffy 16y ago
  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.
  - mfukar 16y ago
    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-hidden-in-linux-closet.html http://theinvisiblethings.blogspot.com/2010/08/skeletons-hid... [2] http://grsecurity.net/~spender/64bit_dos.c http://grsecurity.net/~spender/64bit_dos.c
    - deleted 16y ago
      [deleted]

jrockway 16y ago

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

amackera 16y ago
Exploits for the exploits?