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
since windows is more "single user" oriented, most local exploit flaws on windows do not get very much publicity.
For instance, shatter attacks are still a very large threat for multi-user windows systems
Second, it'll probably be patched rather quickly.
I can only laugh out loud. Read this story for example.
ayershome.org/users/eric
Is there ever a time when you can consider your systems secure against an attacker with physical access?
"uselib" is a Linux-specific extension, and, as a result, has received much less real-world testing than traditional UNIX system calls. Keep in mind that the traditional UNIX system calls have received millions of man-years of real-world testing in large user communities likely to attempt both remote and local exploits. It is not surprising that Linux-specific extensions are at a much greater risk of containing serious security problems.
COPYING, DISTRIBUTION, AND MODIFICATION OF
INFORMATION PRESENTED HERE IS ALLOWED ONLY WITH EXPRESS PERMISSION OF
ONE OF THE AUTHORS.
Is it just me, or is this mind-bogglingly stupid? A security advisory which can't be redistributed freely? Imagine if the same approach was taken to important warnings in the real world -- "There's a tsunami heading towards you... but you're not allowed to redistribute this warning to all the people around you without my permission."
Security advisories should be in the public domain.
Tarsnap: Online backups for the truly paranoid
Incidentially, the finding of exploits found in bind and sendmail has really slowed to a crawl.
It seems that, even though they were written in different times and without security as the first concern, a sufficiently large number of bug fixes will eventually result in code that is almost as secure.
In this context, that's what "local" means: That you have a local account, even if you are accessing it with telnet or ssh.
A "remote" exploit is one that can be used by someone who has a network connection to the machine, but no account on it.
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)
raw diffs to for those brave souls who want them
Time flies like an arrow, fruit flies like a banana.
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!"
This means only that it must be used in conjunction with a process that is exploitable. Let's say, for example, apache was running and there was an exploit available to it. Well, most people would say "oh well.... can't trash the whole machine, the apache user doesn't have the rights." Well once apache is compromised, they can likely find a way to inject the local exploit code for the apache user to run. Once that's accomplished, apache user becomes root user. From there, the machine is 0wned to borrow a word.
Yes it's serious but I expect a fix shortly...
Shatter attack
It's a problem with Win32 messaging if windows aren't secured properly. It's possible for a process to send windows messages (the ones inherited from Windows 1.0) to another process, regardless of what account the processes are running as. There are a few messages (WM_TIMER esp.) that, as a parameter, take an address for the owning thread to jump to. You can also fill the contents of a text box with a message.
Process A is a privilieged service running as SYSTEM. Process B is a malicious program running as a restricted user.
A creates a window on the interactive desktop (a big no-no) with a textbox in it.
B fills the textbox with exploit code with a message and then sends a WM_TIMER or similar to A with the exploit's address. A is now executing the exploit code.
First, there are ways to divide the window handle space into seperate parts, each securable with desktop and window station objects. Both of these are kernel object types with ACLs: you can't send a message to a window unless you have access to the conaining desktop.
Also, the JOB_OBJECT_UILIMIT_HANDLES flag for Job objects will prevent messages from leaving the job.
MS guidelines specifically forbid the use of windows from a priveleged process from appearing on the interactive desktop, since NT 3.51, for this reason. This doesn't stop many third-party app developers from creating insecure apps (virus scanners esp.) that do just that.
Winlogon's windows (press ctrl+alt+delete) are safe because they are on a seperate desktop that normal users can't send messages to.
I'd really like to know what's being done about this pitiful trend of Linux security, where it's 10x as easy to find a vulnerability in the kernel than it is in any app on the system, where isec releases at least one critical vulnerability for each kernel version.
And given his description of how he found these problems, plus his frustration about getting Linus and akpm to reply, his tone is even somewhat understandable.
I was going to make a comment about "rounding up workers for underground C mines", but I figured that didn't sound painful enough.
So, I would like to remind Linus that I will be very useful in rounding up workers to toil in the underground Perl mines.
All that this needs is to be combined with a vulnerability that grants remote access to a machine and you have a serious problem (provided that the remote access allows them to exploit this).
- and if we had some ham, we could make ham and eggs, if we had some eggs... seriously, we could play "what if" games all day long, but let's not blow this issue all out of proportion. It is what it is and nothing more, and at the end of the day it will have resulted in none of the sort of disasters we see on a regular basis with the microsoft platform...
So, as far as the number of vulnerabilities, you can't convince me (as someone in the industry) that Linux "wins". You also can't convince me that the Linux kernel has far fewer holes found than the Windows kernel. The available evidence does not support the claim. However, that doesn't mean that the Open Source development method tends towards greater potential quality than the closed source method.
Also, remember that a local root vuln is only 1 remote non-root vuln away from becoming effectively a root vulnerability. Too many people who think they are responsible admins try to ignore or downplay the seriousness of local root vulnerabilities.
Thats enough rambling for the day...
perl -e 'print $i=pack(c5, (41*2), sqrt(7056), (unpack(c,H)-2), oct(115), 10)'
I keep seeing posts here about somebody setting their grandma up to run $DISTRO but nobody will admit then that said grandma might be easily duped into clicking that link in that e-mail to get the latest cookie recipe (or some other nonsense) and woops! there goes a local exploit and now her box is Pwn3d!
This sort of thing is not as easy as you suppose - in the windows world one can write a quick vbscript to cause all sorts of nonsense, but on a unixlike platform such as Linux there would be a considerably higher barrier to the success of such shenanigans.
It sounds like you're saying this isn't such a big disaster because there aren't that many Linux users...and that strikes me as a ridiculous point of view.
I see you've failed to understand my statement. I'm at a loss as to how my meaning could have been contorted from "a potential local exploit isn't going to cause the sorts of internet disasters as we see regularly with windows" into the bizzare statement "hardly anybody uses linux" - (strokes beard thoughtfully). We can put the lie to that sort of thinking by simply considering the apache webserver, it's market share, and security record, compared to the microsoft iis web server, it's market share and it's security record. And by "security record", I don't mean "counting the number of advisories from all linux vendors and comparing them to the number of advisories from microsoft", which is a meaningless comparison. No, I mean "compare the frequency, scope and severity of the security incidents associated with the two platforms", which would be much more telling.
Yeah yeah, that's the responsible thing to say. But responsible stuff is sooooooooo boring. I mean, if we were all responsible people that wanted stability, we'd all be running kernel 2.2, Apache 1.1, many year old revisions of programs patched to all heck, never install any packages that aren't yet at least of legal age, and still tout ISA support as a bleeding edge feature.
Hmm. Wait, I think I just described Debian Stable.
*is hit by a gigantic potato from the debian crowd*
(Yes, I am aware that stable is called Woody, and the last version was called Potato. But if I said "is hit by a gigantic woody..." i'd probably get murdered. Oops.)
Tired of legitimate data sources? Try UNCYCLOPEDIA