Slashdot videos: Now with more Slashdot!

View

Discuss

Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

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

I run Nvidia cards, so I switched as fast as I could to a KVM-enabled driver, which allows me to run Xorg as a user, not as root. As I recall, the FOSS drivers for both ATI and Nvida allow this currently.

Do the Linux developers put a news announcement out every time there is a bug

No, but all changes to the kernel are documented in the changelog. And security-related bugs are treated the same as any other bugs. They are not explicitly called out as being security related. Linus has been pretty clear on this in the past. A bug is a bug, period. The fact that it's security related is uninteresting (to him, at least).

What are you on about? There a full changelog for the patched code. Do you have any idea how much changes in the linux tree each week? One bugfix is not going to make news other than from a pro-Windows news outlet attempting to make it appear there's a cover up. Try reading LKML if you're stupid enough to think there's a conspiracy going on.

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.

Also, note that this was silently patched with no announcement of the problem.

It was not "silently patched." It would be pretty hard to "silently patch" the Linux kernel, unless you could come up with some other explanation of your changes to the kernel developer. The patch was noted in the changelog like any other patch. No attempt was made to hide it.

Or did you think that the developers should have been screaming about the patch from the rooftops? This is not the first security bug to patch in this way.

A filesystem corruption bug that allows one to link an arbitrary file somewhere would allow a much quicker root exploit than relying on cron!

I think you are thinking about extremely old bugs where cron itself could be convinced to run a program without root privledges as root (or really as the cron job). That is from about 1980 or earlier I think.

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

I assume you mean/etc/cron.daily which is still around, along with its hourly, weekly, and monthly counter-parts.

Check on the linux kernel audit project. It exists, does things like static code analysis and audits most of the code changes for security vulnerabilities. In that last 5+ years they have fixed hundreds to thousands of security vulnerabilities - all silently. It is an official policy of the core developers to handle every security problem via obscurity in short time frame.

The changelog indeed is a gold mine. You can at any point of time find fresh vulnerabilities by tracking it. That leads to every installed and running Linux kernel out there having exploitable known vulnerabilities that have not yet been patched. Every black hat that is interested in Linux kernel knows this and exploits it daily.

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.

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.