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.'"

Comments

How much more 'silent' was than other bugs?

[master_p]

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?

Re:How much more 'silent' was than other bugs?

[stagg]

I'd rather hear about a flaw like this after the fact frankly. I don't think an unpatched exploit needs the kind of publicity that /. would get it.

Re:How much more 'silent' was than other bugs?

[ultranova]

For example, is a bug that corrupts one's filesystem less critical than a bug that allows unauthorized access?

More importantly, is there a difference? Red Hat 9 had - and perhaps distros still have - this nice system where cron would, once a day, run programs dropped into a directory in /etc with root privileges. Very useful for various packages that required periodical maintenance; but if a filesystem corruption bug would allow one to link an arbitrary file to those directories...

A bug means that a system behaves in a way it shouldn't. There's always the chance that such unplanned behaviour can be used by an attacker to do nasty things. There is no difference between security critical and other bugs, there's only bugs with known exploits and bugs without. Every bug is a chink in the armor, and every kernel bug should be considered security-critical.

Is this news?

[mspohr]

Isn't this the way it's supposed to work?

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.

Re:Is this news?

[jpapon]

Must be a slow day. Conspiracy articles about HAARP causing Moscow to burn, and an article about a security flaw that has been fixed. Fascinating stuff... What's next?

Re:Is this news?

[mspohr]

Although this article was about a Linux potential vulnerability and not about Microsoft, you seem to think that Microsoft is treated unfairly with too much publicity. I guess the difference is that Microsoft, unlike Mac and Linux, does actually have thousands of virus infection vectors in the wild and they have been slow to patch their buggy software. It isn't particularly newsworthy when Linux patches a potential vulnerability (with no known exploit) promptly but it is news when Microsoft patches an old bug that has already led to thousands (? millions) of infected machines.

Re:Is this news?

[the_bard17]

Probably since we're not Microsoft. Really.

Who's got access to the Linux kernel's source code? Anyone. Compare that to who's got access to Windows' source code. Who can submit a patch for the Linux kernel? Again, anyone. Compare that to who can submit a patch for Windows.

So if there's an exploit in the Linux kernel, it's our fault... because the only thing holding any of us back from fixing it is our own lack of knowledge, ability, and/or time.

For those Windows exploits, however, we're left at Microsoft's mercy, assuming there's no other way to prevent the exploit than to fix the source code. The same is true for any other closed third party software.

Re:Convenient

[NNKK]

Do you honestly think that Microsoft would do nothing if there was a non-patched privilege escalation exploit in Windows?

What rock have you been living under?

Re:Convenient

[Peach Rings]

They patched it, I don't know what you expect them to do beyond that. "Silently" just means that slashdot didn't pick up on it or something.

Also,

Do you honestly think that Microsoft would do nothing if there was a non-patched privilege escalation exploit in Windows?

Are you kidding?

How fancy can you get?

[gzipped_tar]

can bypass all the Linux fancy security mechanisms, and escalate to root, and compromise the whole system.

The author who wrote this certainly didn't count SELinux as one of the "fancy" security mechanisms...

Re:Convenient

[erroneus]

Yes.... yes I do. We have seen it with the process messaging flaw.

Microsoft is a for-profit company. To make a profit, they have to control costs and increase sales. By paying people to patch vulnerabilities, they are increasing costs. This has the effect of lowering profit. On the other hand, their reputation has impact on their ability to make sales (though admittedly, not as much when you are not a monopoly). So if the flaw is well known (which in this case, became the headline of a great many news stories) they might be pushed in the direction of spending the money to fix it, but since they are a monopoly, it takes a much bigger push to get a flaw like that fixed than if they were in competition with other OS makers. And I am sure they work under some sort of formula that says "If cost of fix x 10 loss of sales then ignore it" or something like that.

So yes, if they felt that the threat to their profits is large enough they will take action... else they will not. Lately, Microsoft is facing a lot of competition so yeah, they are more likely to take action now than ever before. But that has not always been the case, especially during their golden years of "embrace and extend" and other standards-trampling behaviors. They could pretty much do whatever they wanted... and did.

2 Months is Acceptable?

[Arainach]

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.

Re:2 Months is Acceptable?

[drsmithy]

Whatever. He's calling Slashdot biased. Pot, meet kettle.

But Slashdot *is* biased, quite heavily, towards Linux and Open Source (and against anything not anti-Microsoft). Your previous post is, indeed, an excellent example of that bias.

Re:Convenient

[gorzek]

Sure, fixing a bug might take a line or two of code.

But the time required to fully test it and make sure it doesn't break anything else? That's where all the real costs are. It's why Microsoft doesn't generally have a fast turnaround on Windows security fixes.

There's still a hole.

[Animats]

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.

Re:There's still a hole.

[scribblej]

I wouldn't put X11 on a production server in the first place. Why would you?

Assuming you're not serving X11, I mean.