Slashdot Mirror
Local Root Exploit in Linux 2.4 and 2.6
Anonymous Coattails writes "Summary from the advisory: 'Locally exploitable flaws have been found in the Linux binary format loaders' uselib() functions that allow local users to gain root privileges.'"
← Back to Stories (view on slashdot.org)
Read down to the Credits on the link and you see this line:
Credits:
========
Paul Starzetz has identified the vulnerability and
performed further research. COPYING, DISTRIBUTION, AND MODIFICATION OF
INFORMATION PRESENTED HERE IS ALLOWED ONLY WITH EXPRESS PERMISSION OF
ONE OF THE AUTHORS.
Did I violate you buy hitting ctrl-c and ctrl-v? Yeah copyrights stink even in free and open source realm. Oh yeah I guess Polly boy has something to put on his resume now as if someone else was going to steal his glory and get away with it.
Because in this case Linus Torvalds is our new overlord, and I for one, welcome him.
A feeling of having made the same mistake before: Deja Foobar
It's a good thing I've got the patch downloa
ayershome.org/users/eric
Isec.pl has done a lot for the open source world, they've found lots of vulnerabilities (which is good - vulnerabilities ARE like any other bug):
Take a look at the impressive curriculum of those guys:
d_path() truncating excessive long path name vulnerability
Linux kernel do_brk() lacks argument bound checking
Linux kernel do_mremap() local privilege escalation vulnerability
Linux kernel do_mremap VMA limit local privilege escalation vulnerability
Linux kernel setsockopt MCAST_MSFILTER integer overflow
Linux kernel file offset pointer races
Linux ELF loader vulnerabilities
Linux kernel IGMP vulnerabilities
Linux kernel scm_send local DoS
Linux kernel uselib() privilege elevation
Guess what, they're also the guys who discovered the mozilla hole diclosed today: Heap overflow in Mozilla Browser NNTP code
Those guys are impressive. In particular, Paul Starzetz is the author in most of those kernel holes, along with a guy called Wojciech. They always contact the kernel maintainers before discosing the vulnerability, etc. Basically, they're having the same effect than a security audit. Except that they're doing it for free, so they deserve respect, I think. And yes, Linux is having too many kernel-level vulnerabilities. More than XP if I'm counting them right. Perhaps someone should offer a job to those guys so they can audit parts of the kernel better.
(And I can understand that copyright policy - there're people who probably look at those announcements, ctrl+c and ctrl+v and they release their own announcement twisting dates claiming that they're the guys who found it first)
It's quite a bit like Microsoft in one way.
/lib/ld-linux.so switched to using mmap(). If you haven't run an a.out or libc5 executable, it is extremely unlikely your machine has ever invoked this syscall.
The uselib() system call is quite old. It was introduced in Linux 0.12 as a quick way to support dynamically loaded, statically linked libraries.
The way shared libraries worked was like this:
libc was compiled and linked like a normal program would be, except that its start address was set to (say) 0x400b0000. printf() would be at (say) 0x400cb110.
Main programs were linked down at 0x08048000 or so, and knew where in memory printf was. The kernel knew how to load your main program and jump to its start. However, there was nothing but a segfault waiting for you at 0x400cb110 initially. So how did the kernel know what shared libraries to load?
Well, one possibility was to put a list of library paths into the executable and teach the kernel to load 'em. Ugh. Didn't SCO do that?
Instead, the linker would add a little assembly language stub to start your main program. It looked a little like:
uselib("/lib/libc.2.so")
uselib("/lib/libm.2.so")
and the uselib syscall would graft the contents of those files directly into memory, in the same fashion the kernel knew how to load the main program. Voila, calling printf at 0x400cb110 will now work.
Eventually, this switched to a single uselib("/lib/ld.so") so we could have search paths and dynamic linking. But it was a pretty good start.
After we all switched to ELF, uselib wasn't such a good idea, as ELF allows some more clever things than just direct-mapping the whole executable at a fixed address.
As part of the a.out->ELF transition, the uselib() syscall was preserved. It allowed old-style fixed location libraries to be dressed up in new ELF clothing. A few years ago I tried uselib() on MIPS, and had a miserable time trying to get GNU ld to make a library the kernel didn't reject. I gave up.
So how is this bug like Microsoft? The bug is in a mechanism that is a holdover from an older, simpler time. Nobody saw a good reason to take it out. And it didn't get much security scrutiny until somebody said, "hey, what's THAT still doing in my OS? I bet it's got bugs!"
No this was just a dumb locking bug. You could reasonably argue that some of the kernel API's for do_brk were less than well designed but thats more historical accident.
Its fixed by 2.6.10-ac6 along with the setsid crash and some other corner case bugs Coverity found.