Slashdot Mirror
Linux X.org Critical Security Flaw Silently Patched
eldavojohn writes "On June 17th, the X.org team was notified by Invisible Things Lab of a critical security flaw (PDF) that affected both x86_32 and x86_64 platforms. The flaw deals with escalated privileges of a user process that has access to the X server. The founder of ITL said of the flaw, 'The attack allows a (unpriviliged) user process that has access to the X server (so, any GUI application) to unconditionally escalate to root (but again, it doesn't take advantage of any bug in the X server!). In other words: any GUI application (think e.g. sandboxed PDF viewer), if compromised (e.g. via malicious PDF document) can bypass all the Linux fancy security mechanisms, and escalate to root, and compromise the whole system.' This has apparently been a security flaw since kernel 2.6 was released. From the article, 'On 13 August, Linus Torvalds committed an initial fix, but several patches were added afterward for various reasons. The problem has been addressed in versions 2.6.27.52, 2.6.32.19, 2.6.34.4 and 2.6.35.2 of the kernel.'"
Xorg is a mess. Fedora had to craft a special SELinux policy, which exempted Xorg from a number of restrictions that apply to other applications (for example, the ability to unset the NX bit on a region of memory), because not only does Xorg do so many questionable things, but there is no good way to fix it. That, and the fact that Xorg runs as root, make it a particularly weak link in the chain.
Palm trees and 8
Sure, because Legacy Media was so focussed on telling people what was important, rather than just what they wanted to... ooooh, OK! magazine have offered Linsday Lohan $1m for an exclusive - must read now!
If you were blocking sigs, you wouldn't have to read this.
Another reason Linux is safer is that these problems get due attention when reported, but for the windows team puts effort to fix most problems, it has to be a source of embarrassment for the company.
It's not a PDF flaw, it's a flaw in Linux kernel. The malicious PDF file was just an example for an attack vector. You know, the same way it works in Windows. No system is immune to these kind of attacks, the only reason Linux and Macs see them less is because most of the users are on Windows (especially the "stupid" or casual ones). Not even the walled gardens like iPhone, where PDF attack was used to root and jailbreak the system just recently.
You got it spot on. Although in my personal experience I've had more Linux servers compromised than Windows ones. Could be the fact that in general my Linux servers are exposing services to the internet where as my Windows servers are not. Or it could be the fact that at times questionable users (ie: customers) have had access to my Linux boxes. Oh and then there was one time my MS-DOS server was compromised (lol).
In general it's not the OS keeping you secure it's how valuable of a target you are and how vigilant you are at security.
I don't think it's all that weird. For example, is a bug that corrupts one's filesystem less critical than a bug that allows unauthorized access? Is a root escalation bug more important than a bug that prevents one's video card from working? They all need to be fixed, but I don't think security implications entitle such bugs to special treatment.
Ita erat quando hic adveni.
Quickly? This flaw has existed for 7 years.
Xorg throws a wrench into SELinux; just ask the Fedora SELinux policy maintainers. I still remember the days when my Fedora system would pop up SELinux warnings left and right because Xorg was trying to do something stupid and suspicious. These days, Xorg just gets exempted from SELinux policies in Fedora.
Palm trees and 8
Reference please? Which Linux servers? Red-hat? Debian? SELinux enabled?
Sounds like you know a lot about the subject..
This was between 1999 and 2003 when a partner and myself were running a small web hosting/shell company Mach Nine Internet Services, http://www.mach-nine.com/ (under construction now?), http://www.lomag.net/information/news.php
Always Redhat... started with 6 (which was the 2.2 kernel...) and think we ended at 7.1.
In any case this small period of time was the only time I've had Linux servers publicly available on the internet and two of three machines were rooted due to a (2.4?) kernel flaw that made it trivial to escalate privileges if you had a shell (which being a shell provider...). Since then I've had several Windows servers publicly servicing the internet but the difference is that they are for my personal use and not high profile (in relation to my old Linux servers) targets.
My statement was not one about the inherent security of one OS over the other. There is more I could have done to prevent the root attacks on the Linux machines and I don't deny that. I'm repeating myself here but my point was:
In general it's not the OS keeping you secure it's how valuable of a target you are and how vigilant you are at security.
I don't get this blind trust in SELinux can do what it was never intended to do. If you compromise the kernel - especially a monolithic kernel like Linux - it really is game over.
Practically every security check (and - yes - that includes SELinux extra hooks) are performed before the actual operation is performed with no kernel lock covering both. Which means that *all* of them are susceptible to concurrent access attacks.
It works like this: The malicious code invokes the syscall passing a structure, e.g. an inode but at the same time the malicious code starts a second thread which after a measured period (clockcycles) modifies the very same structure. By crafting this carefully the attacker can hit the "weak spot" between the security checks and the actual operation. It doesn't work every time due to obvious nondeterminism, but even a 30% hit rate will be exceptionally good in a mass attack.
And you cannot lock down the tools used in this scenario. All processes will need to access memory and spawn threads. Certainly browsers, X servers, pdf readers etc. do.
This is not a bug in the kernel. Avoiding this weakness would involve bigger locks and critical sections which would seriously impede scalability. It is just that the kernel was never designed to withstand attacks from within the kernel itself.
So please stop peddling SELinux as a silver bullet. Once an attacker is inside the kernel it really is game over. SELinux doesn't fix that. Nor was it intended to.
Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
Here is a novel idea: Stop misrepresenting what actually happened and stop ad hominem attacks questioning posters' motives .
Microsoft took five weeks to prepare the Ormandy patch. During that time, they made no comment - there was no transparency into whether or not it would be fixed.
They made no comments? Did you actually look or did you just assume?
Now to your claim that they "made no comments":
Hardly a "no comments" approach. If you click through those posts I think you'll find them smack full of info. And I've even excluded their communication on the preliminary "fix it" tools.
Admit it. You are biased, but not classy.
Like your misrepresentation and ad hominem demonstrate more class?
It seems to me that it is indeed interesting that this fix was 2 months in the making (responsibly disclosed). And that is only measuring the time until the kernel had been fixed. Now the distros would have to pick up on it and perform their own regression testing, prepare packages/updates etc.
GP did raise some really interesting questions. For some reason you chose to disregard them right away and go straight for the mans posting history.
Will you be publishing stats on my posting history as well. Am I a shill, too?
Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
Your support of an assertion claiming "countless" unpatched privilege escalation bugs is a single, already patched, bug ?
Except, of course, it isn't a microkernel. They ripped that out, first thing, made it monolithic for performance.
I'd love to see a common operating system using a microkernel. That seems to be the only way forward in a world of imperfect programmers and increasing attention towards turning every little flaw into vulnerabilities.
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant