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.'"
So, I'm supposed to click a link to read a PDF about a PDF flaw. You sly boots!
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
Do the Linux developers put a news announcement out every time there is a bug and they forgot about it this time?
Isn't it a little sensational to imply that Linus and the other people didn't want this bug to be known because they fear Linux will be characterized as buggy?
You do realize that Mac is built on a FreeBSD kernel?
Macs can't be exploited. That's why people paid to get into the walled garden, it's safe in there. LA LA LA LA LA LA I CAN'T HEAR YOU.
1. Bug found, responsible parties notified
2. Bug fixed and software updated
3. We are protected from potential future attacks. (Profit!)
Was there an actual attack? No.
I don't read your sig. Why are you reading mine?
Actually, MacOS uses the Mach microkernel in a BSD system; some code was taken from FreeBSD -- but not the kernel.
The author who wrote this certainly didn't count SELinux as one of the "fancy" security mechanisms...
Colorless green Cthulhu waits dreaming furiously.
Darwin is their codename for what is the open source bits of MacOS X. The kernel is largely based on Mach. Since its a Microkernel, it can have "servers" for different subsystems, including BSD, which aren't really "kernel modules" in the Linux or BSD sense. A lot of the userland and C libraries are derived from FreeBSD, with some GNU stuff, and custom changes to both. They did hire a bunch of big-name FreeBSD people though, like Jordan Hubbard, which just contributes extra confusion to a confusing situation.
pedant*
Unless you are actually a piece of jewelery.
"There is a way that seems right to a man, but its end is the way of death." Proverbs 16:25 (NKJV)
Just a few months ago we were blasting Microsoft for taking five weeks to prepare the Ormandy patch. Now we discover that Linux has had a root-privledge exploit for years, was notified, and took two months to fix it, and we get comments like "Must be a slow day." Stay classy (and unbiased), Slashdot.
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*
There's still a hole. See Xorg Large Memory Attacks, section 4. Opening a one-page gap in mapped memory at the top of the stack is a workaround, not a fix.
This looks like bad design. Someone got too cute with the MMU. The basic problem is shared memory between a privileged and a non-privileged program. That just screams "security hole". It was put in to get a performance advantage for graphics-heavy applications on X, probably games. "MIT-SHM" shouldn't be enabled on a production server.
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
Static analysis produces massive amounts of false positives that are easier to "fix" than to verify.
I believe, it would be a safe bet that there are still no actual vulnerabilities found and successfully exploited by this method -- and the actual exploitable vulnerability the article is about, was not and could not be found by such analysis.
So no, changelog is not a "gold mine" for anything, most of the time if will give you massive load of starting pointers that if/when you will find one that is a genuine security bug and produce an exploit based on it, not even the oldest network-accessible installation of Slackware will have them.
This is a rare exception, though it hardly stands out in the changelog, and only coincidence with Xorg [otherwise completely valid and reasonable] behavior makes exploit possible.
Contrary to the popular belief, there indeed is no God.
On a Linux system it's generally "setuid root", which means the filesystem permissions allow program can be run by any user, but there's a special flag that tells the kernel to actually give it root privileges, exactly so that it can do special hardware stuff.
You have to be very careful when writing a program designed to run with an effective ID of root, because it's one of the fastest ways to compromise a system if there's a flaw.
Newer versions of Xorg are moving to an architecture where they can be run without root privileges - there's already patches available, and it's an area of interest for a lot of people.
Workdays was important because that is what was used in the responsible disclosure guidelines. Which recommends waiting 5 workdays of non-communication before taking a vulnerability public.
Responsible disclosure which Google strongly supported until one of their researchers broke it:
From Googles website (emphasis mine):
"This process of notifying a vendor before publicly releasing information is an industry standard best practice known as responsible disclosure. Responsible disclosure is important to the ecology of the Internet. It allows companies like Google to better protect our users by fixing vulnerabilities and resolving security concerns before they are brought to the attention of the bad guys. We strongly encourage anyone who is interested in researching and reporting security issues to observe the simple courtesies and protocols of responsible disclosure. Our Security team follows the same procedure when we discover and report security vulnerabilities to other companies.
Tavis Ormandy knew this. That is why he made a stupid claim that acted in his personal capacity, not as a Google researcher. Even though he used Google resources, Google colleagues and Google paid time.
Also I see no technical discussion of the problem on any of the links you posted, nor any steps that can be taken until MS gets a update out to fix it.
The technical info is there. If you cared to follow the "fix it" links from their blog entries you would see that they designed workarounds.
But the interesting thing here is that after this debacle, 60 days was put forward as an absolute maximum a vendor should spend analyzing and designing+implementing a fix for a vulnerability. With this Linux bug we see 2 groups need to sit down together to work things out. And they spend 60 days before the distros got their hand on the fix. Just interesting, that's all. This was pointed out by the GP of the post I responded to. And he was immediately attacked.
Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*