Local Root Exploit in Linux 2.4 and 2.6 795
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.'"
Re:What, no remote exploit?!? (Score:4, Insightful)
For instance, shatter attacks are still a very large threat for multi-user windows systems
The score so far... (Score:1, Insightful)
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.)
Re:What, no remote exploit?!? (Score:2, Insightful)
Re:Once again... (Score:2, Insightful)
how do you fix embedded devices?
Shouldn't be much of an issue, most embedded devices don't have user accounts.
Re:Interested (Score:1, Insightful)
Do you include the bundled software on your average linux distro...
Kernel to kernel would be interesting.
Embedded devices? (Score:3, Insightful)
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.
Re:Stop posting exploits. (Score:1, Insightful)
Short-term vulnerability in retrun for media coverage and quick patching, or long-term vulnerability while those "in the know" freely exploit.
Former, please.
Only in select modules? (Score:3, Insightful)
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.
Re:Local Access is always a trump card (Score:5, Insightful)
making APIs secure takes time (Score:5, Insightful)
Distribution restrictions (Score:5, Insightful)
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.
Typical biased Slashdotter numbers (Score:3, Insightful)
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.
Re:Failed on Debian 3.1 / 3.0 (Score:1, Insightful)
Re:makes me chuckle. (Score:1, Insightful)
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.
Re:Failed on RHEL (Score:1, Insightful)
/me flips off isec.pl (Score:3, Insightful)
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.
Re:Interested (Score:1, Insightful)
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
Re:*sits back* (Score:2, Insightful)
> 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.
Linux is not invulnerable (Score:3, Insightful)
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.
Re:makes me chuckle. (Score:1, Insightful)
Yawn! (Score:3, Insightful)
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.
Re:*sits back* (Score:5, Insightful)
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!"
Combined with another flaw, it could be bad. (Score:3, Insightful)
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.
Re:Typical biased Slashdotter numbers (Score:3, Insightful)
For those who say "just a local exploit..." (Score:5, Insightful)
Yes it's serious but I expect a fix shortly...
Re:I'll give you one (Score:2, Insightful)
-kaplanfx
Re:Typical biased Slashdotter numbers (Score:2, Insightful)
Linux is just a kernel, taking vulnerabilties in "Linux" is irrelevent. You need to look at a distribution, and all distributions are different, and many FORCE you to choose options (even if you don't want to).
From my memory this is the first "Linux" privelege escalation I recall for quite a while, but it is also local. Windows has had probably about 10-12 in the last year, and many of those were remotely exploitable. (note those are vague ballpark estimations) But again you have to use the context of a distro for comparison.
Re:Typical biased Slashdotter numbers (Score:0, Insightful)
Apparently, there are a lot of people like you who believe otherwise, supporting a pseudo-fascist opinion state where anybody who disagrees with the talking points are flushed out of the system.
Re:Combined with another flaw, it could be bad. (Score:5, Insightful)
- 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...
Re:/me flips off isec.pl (Score:2, Insightful)
Personaly I say more power to people that are taking the time to find flaws in Linux and make them public in a manor other than letting a worm rip out. On the including the code, it looks like this is a tricky one to exploit. If someone finds an issue with my code, I thank them for showing me where it fails and how to reproduce it. It saves me time.
That and I think we need a little rattling now and again. Simply having the belief that you are running a secure system can lead to bad things. Reminds me of progs like AirSnort. Thinks like this are too easily brushed off as 'theoretical' until someone puts out code to prove it.
Re:*sits back* (Score:5, Insightful)
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...
Re:Combined with another flaw, it could be bad. (Score:5, Insightful)
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.
Re:*sits back* (Score:2, Insightful)
Re:*sits back* (Score:4, Insightful)
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.
Re:How do universities, etc. deal? (Score:4, Insightful)
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.
Re:*sits back* (Score:3, Insightful)
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
Re:*sits back* (Score:2, Insightful)
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.
Re:Combined with another flaw, it could be bad. (Score:3, Insightful)
Dangerously wrong. It is incredibly common for web applications to have holes that allow execution of arbitrary programs. A "local only" vulnerability is the other half of the weakness an attacker needs to turn a simple coding or configuration error into a root exploit.
Re:What, no remote exploit?!? (Score:3, Insightful)
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.
Re:Combined with another flaw, it could be bad. (Score:3, Insightful)
I don't think you understand what security through obscurity is, and your reasoning is the same old joe sixpack thinking that we've heard before, that linux has a better security record only because it has a smaller user base than microsoft windows. By that same logic, apache should have a horrible security record - and yet, although the apache source code is open to the world, it has both a significantly higher market share, and a better security record than the closed source iis.
Re:*sits back* (Score:3, Insightful)
Re:*sits back* (Score:3, Insightful)
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