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)
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
It's a straight fight so far in the Privilege Escalation match in the past year, so let's look in on our contenders:
Windows (all versions) 100
Linux 1
It looks pretty bad for Linux until you consider that this game is scored like golf, and then it's all tears and jeers in Redmond.
Back to you, Cowboyneal.
(NB. I know there have probably been other Linux kernel exploits, but this is the first in recent memory.)
Because Linux is a kernel, with no real knowledge or direct interaction with outside (remote) sources, while Windows is a kernel plus a GUI plus a ton of other services. Remote exploits aren't found in the Windows kernel, they're found in the application/service part of Windows, on the Linux side these buggy, infinitely exploitable services are given individual names like "sendmail" and "bind".
how do you fix embedded devices?
Shouldn't be much of an issue, most embedded devices don't have user accounts.
Trolling is a art,
its difficult to compare windows vs linux. in a scientific fashion atleast:
Do you include the bundled software on your average linux distro...
Kernel to kernel would be interesting.
How do you fix embedded devices? Um... you mean how do you update/patch the code on the embedded device so that a local user can't escalate to root?
First of all, for many embedded devices, this isn't an issue. I mean, if you're an attacker, what are you gonna do once you get root? If the owner can't patch the OS, you probably can't install a rootkit either. Sure, you can DOS it, but if you're physically at the device, you can DOS it just by hitting the power button.
However, manufacturers of all embedded devices (not just Linux-based!) should definitely put a mechanism in place for updating the program code.
Troll or not, not posting will just end up with more vulnerable boxes.
:)
Short-term vulnerability in retrun for media coverage and quick patching, or long-term vulnerability while those "in the know" freely exploit.
Former, please.
I should mention that enabling ELF format is still highly recommended (after the patch for this is released of course) and unless you do special programming work in linux then enabling a.out format is not recommended.
Well, yes and no. There's a difference between being vulnerable to those with physical access (pretty much always true, but very limited) and vulnerable to those folks with the ability to run something on your machine locally (fewer than true remote users, but much higher in number than those folk with actual physical access). All you need for this exploit is a way to run unpriv. code on the machine. Note that using a network exploit to run said code is a great way of gaining access - suddenly the fact that your webserver is running as "nobody" doesn't really matter any more.
You're special forces then? That's great! I just love your olympics!
"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
Right, let's compare the flaw in a single kernel versus the ENTIRE OPERATING SYSTEM of Windows, GUI, shell, and associated apps like Internet Explorer as well as user-ran executable attachments in Outlook, which have nothing to do with Microsoft.
What happened to all the "Linux is just the kernel" stuff? Oh, that's right, we were bashing Microsoft.
Besides, if you mean "past year" as 2005, then this means Linux is first out of the gate.
Same compile errors, tried with gcc-2.95 gcc-3.3.5 gcc-3.4.
The idea that 'Once Linux gains enough momentum and is deployed on a meaningful percentage of business users desktops, hackers will deem it worthwhile to devote time to exploit it', while having some merit, is far too simplistic. Sure more "hackers" might attack Linux if it had more market share, but that doesn't mean that more exploits would be found, especially if the system is inherently more secure.
In addition, just because Windows is the most wide spread OS and likely to receive the most attention, does not excuse MS from its poor programming and implementation.
it was intended for GCC 2.X, never tested on 3.x.
why did they release exploit code before a fixed kernel was released and mirrored throughout kernel.org? and on a friday afternoon?
i'm not too impressed with the timing of this announcement, and i have to wonder what their motives were. it doesn't hurt their cause that slashdot is advertising for them.
please, people. there's no reason that a situation like this should ever happen.
Probably now because unix software collectively has been around a lot longer than Windows and most of the exploits which were there originally have been fixed. Linux is a relatively new unix variant but it still benefits from the experienced gained in older variants.
When windows NT is 20 years old it will be much less buggy
http://michaelsmith.id.au
at poolsize_strategy(): /* /*
> int len;
^ signed integer
>
> sysctl_poolsize = random_state->poolinfo.POOLBYTES;
>
>
>
>
> * We only handle the write case, since the read case gets
> * handled by the default handler (and we don't care if the
> * write case happens twice; it's harmless).
> */
> if (newval && newlen) {
> len = newlen;
^ unsigned int converted to signed
> if (len > table->maxlen)
^ comparison of two signed integers
> len = table->maxlen;
> if (copy_from_user(table->data, newval, len))
^ copy_from_user with len possibly > table->maxlen
Is it just me or does newlen > max_signed_int mean len < 0
If so, that would be interesting.
It is important to know about, in my opinion. But that's just so we know we need to patch our kernels. Simply the fact that a root exploit has been found does not mean we should go about reposting the same types of stuff that has been posted endlessly before in similar articles on slashdot.
I prefer linux because it's free. It's also pretty stable and secure, which is nice. But I just like linux for what it is. I fear we are getting sidetracked in the "my OS has less exploits then yours, nanananaaaaa" childish type of fights.
I look forward to the updated kernel which will fix this issue for my distribution. Until then, I'm going to do some much needed maintenance on my box and barricade my room so no one but me can get in.... just kidding.
ahhh, flamed by an anonymous coward. I was referring to the fact that it is incredibly easy for others to point fingers at the poor programming and implementation that you mention occuring over in Redmond. Last time i checked they recruit some of the brighest minds in the world (heck i didnt make it past lunch in my interview ;) and spend more on research and development than any other company in the world. I believe that their intentions are coming from the right place, however in practice they have issues (much like communism) since their ultimate goal is to appease shareholders by making money. Sacrifices (it seems) are made to get product out the door.
The sheer infrastructure and process needed to build, deploy, and distribute, not to mention maintain software (specifically operating systems) would bring the linux world to it's knees in about a month should every MS product in the world dissapear. bet on it.
I am by no means a large MS fan, however i find the holier than though attitude adopted by a large number of the linux crowd hysterical.
This of course, is just my humble opinion.
-R
What news is this? There have been local exploits in the Linux kernel before, and there will be again. This is less news than the Debian break in a while back - that was worth mentioning because a major Linux installation was comprimised with an unknown kernel vulnerability. But come on! The last few 2.4 kernels (IIRC) have included patches to fix local root exploits. Marcello didn't even rush those out the door. This exploit certainly doesn't seem especially unusual nor was there an exploit in the wild.
Newsflash kids! Linux isn't perfect! Certainly not Linux specific API extensions like uselib. Move along, this isn't the kernel vulnerability you are looking for.
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!"
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).
All flaws need to be fixed. Even ones you don't think are very important because they could be exploited together.
It doesn't matter how many holes Windows has compared to Linux. The exploits are usually scripted and tied to a port scanner. If you're vulnerable, you will be cracked.
That's why multiple levels of security are a Good Thing (tm). Defense in depth is the only way to go.
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...
You are just giving support to all the linux zealots out there. So what you are saying is that its worse to have a kernel exploit, than to have an os which can be crashed and seriously exploited from userland programs? I don't think so, linux tends to be pretty good at prevent user space programs from accessing or exploiting the kernel and thus crashing the system, windows has serious problems with this... like why are the web browser and user interface directly tied into the kernel.
-kaplanfx
Visualize Whirled Peas
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)'
2.2 is not affected by the bug. If you're interested in rock stability, drop 2.4. Some people use 2.0 still.
"Long run is a misleading guide to current affairs. In the long run we are all dead." (John Maynard Keynes)
Then run a different distribution. On Debian a new kernel is just an apt-get away, no compiling required (unless you need something special of course). I'm sure other distros are similar.
When you lose something irreplaceable, you don't mourn for the thing you lost, you mourn for yourself. - Harpo Marx
In short, this one is too big (too exploitable, too public) to wait until Monday.
My life would be so much easier if profs didn't have such a hard on for Linux and let us admins install OpenBSD. Good thing I get paid overtime. Oh wait, I don't.
Serve Gonk.
For one thing it works. For another we admit it. For a third we don't have to lie about it.
.... it's mine. Period.
Oh yeah. I've never yet seen a local exploit on Windows. This is true. The number one exploit from Console on Windows is usually turning on the box. Once I do that I really don't care what you've done. I own you and I'm root (Yes even with WinXP SP2 and the supposed user password protection.)
Note too to be fair. ANY box where I am at the console I don't need fancy exploits and code to grab root etc. Once I've sat down in front of the keyboard
I'm sorry, I'm to tired to be witty at the moment so this message will have to do.
Oh, yes, that's what the link claims. But of course there's a remote execution server involved. Just like on any other OS, something must be sitting around waiting for the client and letting it in.
The thing that is special for Window in this case seems to be that it isn't ssh, and I'm not sure that's something to be pleased with.
Consoles apps (not consoles themselves*) are not vulnerable because they are not part of the windowing system, they output to the window via stdout/stdin/stderr.
As for X, I don't know the structure of the windowing system, but the basic problem is not that apps are broken into, the problem is that any window sitting on your desktop is assumed by the OS to be owned by YOU. So, it shouldn't be illegal for a different app owned by you to send it a window message (like typing "rm -rf /").
* A console app is any app like cp or mv that you can invoke from a command prompt. These apps are unaware of windows and its messaging structure and therefor not vulnerable. Cmd.exe itself is probably aware of the messaging system though, since I'm sure it actually implements its own console.
In this case, local means you are logged in as a user already. It does not mean you are physically at the machine. This kind of exploit is why Remote User Exploits are actually a serious issue even though they might not give you root access directly. All you have to do is combine an exploit that gives you user-level permissions with a Local Root Exploit to get root access.
*awaits justifications and explanations of why this is nothing like Microsoft*
This is a local exploit. These are so common in Windows that nobody talks about them anymore. Most reported Windows exploits are remote exploits (exploitable over the net) or application exploits, e.g. in the bundledbrowser or Email apps.
Really no comparison at all
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.