Linux kernel purged of five-year-old root access bug The Linux kernel has finally been purged of a privilege-escalation vulnerability that for at least half a decade allowed untrusted local users to gain unfettered rights to the operating system's most secure locations. Maintainers of the central Linux component issued a patch last week that killed the bug, which allowed …
> the Linux fanbois wouldv'e ripped Microsoft a new one by now...
The Linux Zealots would never have noticed what with all of the real exploits and trojans and worms out there in the wild causing havoc and bringing the internet down and whatnot.
With Windows, there's plenty of low hanging fruit.
If this had been a five-year unfixed Windows flaw, the regulars of the Reg crowd would have gone nuts...
Have there ever been any local privilege escalation vulnerabilities in Windows that have gone unpatched for five years after their disclosure? EVER? I'm not sure what the answer is, but probably not.
Sensationalised article here:
-- Neolithic Windows security hole alive and well in Windows 7
-- http://www.itworld.com/security/93442/neolithic-windows-security-hole-alive-and-well-windows-7
Well-written technical write-up here:
-- [Full-disclosure] Microsoft Windows NT #GP Trap Handler Allows Users to Switch Kernel Stack
-- http://archives.neohapsis.com/archives/fulldisclosure/2010-01/0346.html
Last I checked, 17 > 5...
Be that as it may, pride has oft been the downfall of many an OS/Kernel developer. Even Linus himself has been called-out on occasion:
-- "That does not look like a kernel problem to me at all," Linus Torvalds is quoted as saying in an email message. "He's running a setuid program that allows the user to specify its own modules. And then you people are surprised he gets local root?"
-- Excerpted From: On Bugs, Viruses, Malware and Linux
-- http://www.linuxinsider.com/story/67818.html?wlc=1282255849
No operating system is perfectly secure. In fact, I would venture to say that anything more complicated than an 8080/8085 executing:
-- 0100 NOP
-- 0101 JMP 0100
is probably in some way "insecure."
But how many years after the *disclosure* of the vulnerability? Whether Linux or Windows, the issue is not how many years the problem lay hidden in waiting, but how quickly an update is released after the world becomes aware of it.
Here was an 8-year-old Linux vulnerability, at the time, but it was quickly patched:
http://archives.neohapsis.com/archives/fulldisclosure/2009-08/0174.html
But is still 17 > 8
What was the oldest outstanding vulnerability ever discovered? Was it in Windows, Linux, or something else? Probably the ENIAC.
17 Years might be the Window NT DOSBox bug, but it wasn't know about for 16.9 of those years. It would guess that the .LNK bug is also about 17 years old and fixed within a few weeks.
It sounds like this Linux bug was found 5 years ago and known about for 5 years as well.
Which is worse? Does it even matter?
The OpenBSD group discovered a vulnerability in the BSD version of yacc that dated back to 1975 - coincidentally the same time I was at Cal...
IIRC, the OpenBSD dev's found the problem when the Sparc64 port of yacc was dumping core. I would guess that porting software to different architectures uncovers more bugs than the "many eyeballs" approach.
*note I made a mistake in my first reply to this message in that I said the xf86 aperture driver was only for the x86 platform so I'm reposting this with the correct info* :
"One important aspect the attack demonstrates, is how difficult it is to bring security to a desktop platform, where one of the biggest challenges is to let applications talk to the GUI layer (e.g., X server in case of Linux), which usually involves a very fat GUI protocol (think X protocol, or Win32 GUI API) and a very complex GUI server, but at the same time keep things secure,”-- Joanna Rutkowska, a fellow security researcher at Invisible Things Lab blogged.
OpenBSD has achieved the so called 'difficult' a secure implementation of GUI X functions : server and client. It achieved this two ways. It uses, for instance, a thoroughly audited xf86 kernel aperture driver (that doesn't even run at security level 0. OpenBSD has various runtime security levels), for xenocara. Xenocara is OpenBSD's implementation of Xorg. The reason why OpenBSD uses its own forked version of Xorg is because Theo De Raadt has long known that stock Xorg is insecure (some platforms worse than others e.g. x86) Xenocara is OpenBSD's secure version of Xorg. So that is why OpenBSD is not vulnerable to such a security bug and Linux is. OpenBSD's security is epic and this is just one small example of why.
http://xenocara.org/
http://www.openbsd.org/cgi-bin/man.c...86&format=html
A quote from the above article :
"One important aspect the attack demonstrates, is how difficult it is to bring security to a desktop platform, where one of the biggest challenges is to let applications talk to the GUI layer (e.g., X server in case of Linux), which usually involves a very fat GUI protocol (think X protocol, or Win32 GUI API) and a very complex GUI server, but at the same time keep things secure,”-- Joanna Rutkowska, a fellow security researcher at Invisible Things Lab blogged.
OpenBSD has achieved the so called 'difficult' a secure implementation of GUI X functions : server and client. It achieved this two ways. It uses, for instance, a thoroughly audited aperture driver e.g. xf86 (this specific driver is for the x86 platform) kernel aperture driver (that doesn't even run at security level 0. OpenBSD has various runtime security levels), for xenocara. Xenocara is OpenBSD's implementation of Xorg. The reason why OpenBSD uses its own forked version of Xorg is because Theo De Raadt has long known that stock Xorg is insecure (some platforms worse than others e.g. x86) Xenocara is OpenBSD's secure version of Xorg. So that is why OpenBSD is not vulnerable to such a security bug and Linux is. OpenBSD's security is epic and this is just one small example of why.
http://xenocara.org/
http://www.openbsd.org/cgi-bin/man.c...86&format=html
As I recall Linux was derived from previous strains of Unix and included uncorrected bugs from its predecessors. There was one such bug that was finally spotted a couple of years ago that had been in the Unix kernel code since the 80s, a 32-bit multiply routine which returned a 32-bit result, not a 64-bit value as it should have. This bug was in the Linux kernel from day one and stayed there until recently.
So yes, Virginia a 16-year-old OS CAN have a 25-year-old bug.
Well, I suppose, but if you have local access to the machine, you can lean over and hit the power button on the front, reboot with only a bash shell as you kernel, remount the filesystem input/output, and reset the root password. That's how you recover a root account on a machine that someone has lost the root account on.
In fact, thinking about it, if you had physical access to the machine, and wanted to cause it harm, you could just hit it with a big axe.
> ...you can lean over and hit the power button on the front, reboot with only a bash shell as you kernel, remount the filesystem input/output, and reset the root password.
Ummm... Not quite. The "bash shell" is not a kernel; it does not provide access to any core, system-level functionality on its own. It requires at least a very minimal kernel to be loaded and running first, before it can do its thing.
> In fact, thinking about it, if you had physical access to the machine, and wanted to cause it harm, you could just hit it with a big axe.
Probably. Unfortunately, most people who would go through the trouble of obtaining physical access to the machine would probably find it to be a much more valuable item in working condition.
But yes, in principal, the kind of attack you describe will work, provided the mass storage device(s) used by the target machine isn't (aren't) encrypted.
However, a hardware keystroke logger interposed between the target machine's keyboard and the machine itself can easily help you get around the encryption issue.
Which is why I recommend that anyone who uses the latest Ubuntu-flavoured versions of GNU/Linux follow the instructions presented here:
-- Ubuntu Lucid Lynx 10.04 Full Disk Encryption with USB Key Authentication
-- http://lfde.org/wiki/index.php/Ubuntu_Lucid_Lynx_10.04_Full_Disk_Encryption_with_USB_Key_Authentication
... especially for laptop users (no warranties expressed or implied, and I didn't write the article at the link provided above), and periodically check your keyboards/mice to make sure they aren't being sniffed in some way.
>> ...you can lean over and hit the power button on the front, reboot with only a bash shell as you kernel, remount the filesystem input/output, and reset the root password.
>Ummm... Not quite. The "bash shell" is not a kernel; it does not provide access to any core, system-level functionality on its own. It requires at least a very minimal kernel to be loaded and running first, before it can do its thing.
Ah, but you select to boot into single user mode, in which you are in a terminal and Bash as root. From there, do as you wish; the machine is yours. The poster you quote may not have worded it well, myself either for that matter, but the effect is the same.
"If it's a case of simply needing to run a malicious X program, then presumably it could be done remotely over ssh -X for example."
The reason it works is that the X-server needs access to hardware (video memory) that most processes don't. You can root the X-server - which will grant access to the same machine as the X-server, i.e. the machine behind your screen.
This won't help you gain access to the remote machine running the x programs. X-servers run on client machines, not on remote servers.
> If it's a case of simply needing to run a malicious X program, then presumably
> it could be done remotely over ssh -X for example.
Nope. The X server runs on the local machine. No GUI of any sort needs to be
running on a server if you are running an X application on it remotely. The part
of X that needs to do root level bit-banging and would cause the problem is going
to be running on the machine that is the "terminal".
Yeah, geez, requires local access to machine. And the Windows wankers still don't even understand the glory of NT gaining it's acceptance into US gov procurment circles by passing the security tests for a server - by not being hooked to a network.
Once again proving the evolutionary advantage of have the palm of your hand the exact size of your forehead ....
*****Local access is not the same as physical access.*****
There is no requirement on location for local access. A local user is simply a user with an account that is local to the machine in question. This is contrasted with a user that does not have shell access to the machine, such as a person viewing webpages on the machine. Alternatively, a local user can be compared to administrator or root access, which have access to sensitive portions of the system. Local users can usually run many programs and are the standard user type on the majority of secured systems.
If an individual does not have local user access, then it can often be obtained by exploiting an unrelated vunerability in the system that gives the individual access to a shell prompt. Then a privileges-elevation exploit of this type can be used to gain full root access to the system without ever setting foot near it.
Pedantic note: a local user is more properly compared with a domain user. However, the primary difference between the two is only in where the account is viable and not in the privileges assigned to the account.
They reported it to Linus and co mid-June, kept quiet and waited for it to be fixed in the kernel, then published their paper. It's only sensible to have fixed it but no need to panic. You have to remember that in Linux, you can't download a dodgy executable from the internet (or attached to an email) and run it by double clicking it (or just opening the email, or following the link). Nobody using Linux installs dodgy software either because they don't need to - it's all free and open source, from a trusted source (the package manager). This is why "exploits" such as this don't get exploited in Linux.
"Nobody using Linux installs dodgy software either because they don't need to - it's all free and open source, from a trusted source (the package manager). "
Nice to see that even the Linux fanbois don't believe in commercial software on their penguin infected boxes. And here I thought they were interested in having commercial games and specialized high-end software suites running on Linux.
"This is why "exploits" such as this don't get exploited in Linux."
I'm glad you've been lucky enough to never have your computer hacked. I've had the "fun" of cleaning up after a Linux fanboi who couldn't be bothered to patch or check the logs on the server he was in charge of. Privilege-escalation exploits are usually pretty useless on their own, but they can be used once a hacker has shell access courtesy of another exploit. The one I had to clean up was the victim of a copy-pasta privilege-escalation hack from a readily available website. The script kiddie probably got shell access through a brute force ssh attack, but might've attacked another publicly available service instead.
Privilege-escalation exploits are only harmless if you can say unequivocally that noone can get access to the machine, even an authorized user.
Linux is a commercial bit of software, just because it's open source doesn't make it a charity or a governmental institution. Or perhaps you think open source is some sort of hobby?
Commercial == Your paid to write code
Free and Open Source == Your Users aren't treated like chumps
I'd like to get paid for not treating my users like chumps please.
> Nice to see that even the Linux fanbois don't believe in
> commercial software on their penguin infected boxes.
If you take the average person's box and take off all of the stuff that represents 5 or more shovelware updates over 10 or 20 years or more then you don't have much left really. Most of what's on a common PC is strictly "commodity" stuff that should be pretty much devalued by now. Some of it isn't because of proprietary standards that interfere with the replaceability you have with proper physical commodities.
A word process or web browser that's mostly unchanged for years and years should be gratis.
Although the real problem with something like Windows is not the stuff from EA or even the stuff from Penumbra but all of the random stuff out there written by who knows who that can somehow manage to get automatically run for you.
Creating a freeware trojan for Linux or any other Unix should really not be such a big deal if the local root exploit is available. The problem is running it. the trick of a proper virus is propagation.
You can download and run a dodgy executable from the Internet with a trivial bit of social engineering - in the order of the sort of social engineering used for MS attacks.
Your assertion that no-one uses closed source commercial software on linux would be fairly well challanged by IBM, Oracle, Symantec, EMC, etc. etc.
As for Repos being trusted - I trust them as much as I trust updates from MS, in that they're probably ok, but I'd wait for others to install from them first.
"which allowed unprivileged users to gain root access. While Linux overlords stopped short of declaring it a security vulnerability,"
So what DID they call it? I'd say, pretty certainly, that a hole - whether exploited or not - they can be used to elevate a user to root privileges IS a vulnerability. Maybe they didn't want to say it in quite those words as it would destroy all the illusions about Linux.
PS: Don't downvote me for that, I'm not saying Linux is as bad as Windows, you'd need to configure telnetd to greet people with a message saying "the root password is xyzzy" to make it as bad as Windows. ;-) What I *am* saying is that NO system is invincible, NO system is unhackable, and living with rose-tinted glasses thinking <x> will never be compromised isn't exactly the best attitude to have.
I think one of the main reasons this bug wasn't given a high priority is that the Xorg server is currently being modified to work in non-root mode, precisely because of bugs like this, eliminating the problem at its root (pun intended).
It is just taking them a little longer than expected so I guess the kernel developers got tired of waiting and squashed this particular bug just in case.
... the vulnerability is question:
a) Needs local access, and if a person has local access he can do a whole lot, vulnerability or not
b) Requires a program to be "setuid" (Eg, allow root operations); how does such a program get on the box without root permissions in the first place?
c) Allows the program to load custom modules; how do the custom modules get on the box in the first place without root access?
This "free-bashing" (ie, it's not a corporate product, and thus cannot be secure) can only fool those without real knowledge about the vulnerability, and serve as ammo for FUDdies.
the "fix" is basically a code cleanup; move along now, nothing to see here, not now, not ever.
This post has been deleted by its author
Your typical home-user wouldn't have the nous to keep their computer in a state that would allow it to run for months at a time without a reboot. Partly because they load every piece of malware they can get their hands on and partly because windows still suffers from bit rot and will tend to become crap after a while just from continued use.
The point is twofold: Linux distros don't, as a rule, require a reboot every time an update is applied (and if you're running a live kernel patcher like ksplice they may never need one), and they are less vulnerable to maintenance neglect - that is, you don't have to keep cleaning them in order to maintain reasonable performance. They just work, to coin a phrase.
"Still, its ability to remain unrepaired in the kernel for more than five years challenges the contention among many Linux boosters that the open-source platform is more secure because anyone can examine its source code."
No, it doesn't. Not even a little bit. The problem here is that you need people who understand the issues and can fix them. The difference is that for closed source those people need to have been found, recruited, and be presumably in the pay of the owner of the closed source, which in turn means it needs to have understood the necessity of doing so, having found the budget instead of just hoarding the cash, and so on and so forth. A certain well-known vendor publicly admitted that "security was not a priority" for over a decade. The open source community's patience is much less than that. With open source at least a source patch can be written, where with closed source the options are much less viable.
Thus, open source _can certainly be_ more secure than closed source in the same sense that dvd's css would've been a lot harder to crack had it been publicly reviewed and improved prior to wide deployment. Whether someone stands up to do it now that they can is another question entirely. Some people did. Why others didn't is a good question.
"But that only begs the question why such a fix was never incorporated in the kernel."
Yes, that it does. After you've written your patch, getting it into the kernel can be a right pain down to impossible. And that would be because "the community" is a bit dysfunctional, with all of those high profile big ego super smart guy developers running around not being very sociable at all. Being a meritocracy doesn't mean having social skills has no merit.
That certain other vendors are, by all indications, well beyond "a bit dysfunctional" is not really an excuse. The community still needs to gets its act together.
Beyond that, this is a local root escalation, meaning that you already have to have access so you can improperly elevate that to root, and standing wisdom has it that if you don't trust the local users you don't put anything sensitive on the box. Meaning that this'll give users more access than intended but not more than basic prudence has me calculate with anyway. It doesn't even come close to some _designed in_ "features" that you can't turn off or remove at all that certain closed source vendors put into their offerings. Still, it's good to have this sort of thing fixed, even if, as rightly commented, it's quite hard to do.
The root exploit works because the X server (running as root) allows unprivileged process to direct access to its memory space, and permits those unprivileged processes to allocate so much memory that it gets dangerously close to the stack. The X server also allows those processes to send commands causing the X server to use large amounts of stack space.
This sounds entirely like a design flaw in X to me. The new kernel stack guard page is a good way of protecting against this design flaw (and other similar ones in as yet unknown programs). It would have been nice if the kernel stack guard had happened 5 years ago when a possible weakness was identified.
It is worth noting that the stack guard reduces the exploit from being a root exploit to being a X server crash (with SIGBUS) so it is still a denial of service attack in X.
"But that only begs the question why such a fix was never incorporated in the kernel."
Exactly. It's not that SuSE/Novel adopted the 'sod you' approach to open source development. Maybe I'm getting confused between GPL and CCL, but isn't there a whole chunk of it that says anything derived from an open-source item can only be reissued under a similar license?
More like no-one's looking at the source code of a major Linux player. Maybe they issued it back to the community but like plrndl asks, maybe there's no real-world exploit and it hit the bottom of the priority list.
Okay, reading through this I think people are overreacting.
Yes, this is a vulnerability.
No, the fact that this requires local access pretty much means that fixing the problem is typically a waste of time since anyone with physical access likely doesn't need or is even likely to take advantage of ANY exploit to compromise a system. THAT is why it went unfixed for five years, there are actual zero-day exploits that are much more worth a kernel developers' time to fix, not that Linux has a heavy amount of this.
Microsoft's problem is that it DOES have what would be considered high priority exploits go unanswered for YEARS before they fix it, if at all.
Okay, now, this might have to do with X requiring suid root. Something being actively resolved and has been for some time with a lot of desplay drivers. The means of the fix of this problem? KMS. Kernel Mode Switching, allowing you to change display modes and use displays beyond displaying something without requiring root permissions to be had SOMEWHERE.
Fortunately, almost all the open source video drivers in the kernel support KMS or will in the near future. The trouble is with old or unmaintained drivers. And unfortunately nVidia has yet to put KMS support in their drivers. However, Nouveau does have KMS support, but none of the features one would want like production-quality 3D acceleration without a helper.
Thing is, even if X manages to get non-suid state within a year we still have one issue, there WILL be a program, SOMETHING, that requires suid root to work. Like sudo. Sudo uses suid root, but its configuration is pretty much designed for explicitly detailing who can do what and how they must authenticate. And often some sudoers aren't actually configured to have root permissions at all, but access to another user.
All in all, this is not really news or an issue.
And the reason I think it's annoying when we Linux users point out Windows bugs is simply because it shouldn't surprise us anymore when there's a huge gaping hole in Windows Microsoft ignores for years.
Take a look at the Xorg code, and tell me if you want to analyze it. (I'll save you the time: the answer is no.)
X is a quagmire of decades-old code, bizarre hacks, frightening memory and hardware usage, all sorts of suspicious behaviors (the Fedora maintainers give it a free pass now, for example, because it manages to trip every selinux rule they try to give it). Basically, it's huge and complex and running as root. This is a Big Problem, but not an unknown one. This bug caught nobody off-guard.
Work has been going on for years to get X running without root access. We're nearly there - modesetting is now done in the kernel, and a few people have actually got X running without root access. So look for it in the next version or two of the major distributions.
"No, the fact that this requires local access pretty much means that fixing the problem is typically a waste of time since anyone with physical access likely doesn't need or is even likely to take advantage of ANY exploit to compromise a system. THAT is why it went unfixed for five years, there are actual zero-day exploits that are much more worth a kernel developers' time to fix, not that Linux has a heavy amount of this."
No, you underestimate the kernel people, they won't decide some flaw is a "waste of time" and not fix it. I've seen bug fixes to error paths in drivers, where the person patching admits they are not certain if that error path is actually EVER triggered (it'd be for some highly irregular situation like a card being physically removed mid-transfer), but they found a bug so they fixed it. Apparently, some distro kernels have had a fix since 2004. There was just some screwup so the patch was not put into the mainline kernel.
---------------
As for UNIX code in Linux -- there's absolutely nothing like that in the kernel. However, the GNU utilities, and other utilities, significantly predate the Linux kernel. I got an error a few years ago (well, maybe 10) "Not a teletype", and investigating it found the error was from code put into the utility I was using around 1976. Also, it follows POSIX standards, and a lot of UNIX paradigms that predate Linux, sometimes by decades -- I think it's unlikely that some fundamental design flaw is found after this long (as opposed to a Linux-specific implementation flaw), but I won't say it's impossible. So, certainly there could be vulnerabilities found in a Linux distro that predate the Linux kernel.
---------------
As for "Linux versus Windows", the example of the 17-year-old hole in the NT VDM. I would just like to point out, Linux had a similar hole in the VM86 system (used by dosemu to run DOS apps) -- for about a month. Within like a month of the VM86 system being put into the kernel, someone ALREADY found a similar flaw to the one hidden in NT VDM for 17 years, and fixed it. BECAUSE they could see the source and see things were not quite right.
Secondly, see MS08-068. Disclosed in 2000, exploit code out by 2001, patched in 2008. After this exploit was disclosed it took over 7 years to patch. I can't find them right now but I know for a fact there've been several other flaws *disclosed to Microsoft*, that they've taken well over 5 years to fix.
Honestly, though, the biggest problem I've seen with Windows security in general is not the odd exploit (that requires code to execute on the system to exploit), it's the fact that people keep finding so many ways to cause code to execute on the system without the user's permission to begin with.
This post has been deleted by its author
the point is that one has to understand what the description of the bug says.
it says you need to have physical access, in other words, you need to login at the system itself.
that is very much different from the 1 upto 5 or 6 *anonymously exploitable* severe vulnerabilities that some famous firm gives you every 2nd tuesday of each month...
I am sure that we agree that we usually can easily notice when an unknown person is sitting behind our beloved PC, right ?
We probably also agree that being hijacked from a anonymous webpage is *a lot more difficult* to notice, yes ?
good.
Understanding is al we need in this barren world....
( oh, yes, I am using both windows and linux all the time, so spare me the fanboi sticker on the forehead. or give me both ......... )
regds AC
agree ?
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
