Linux X.org Critical Security Flaw Silently Patched 259
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.'"
Re:Blame Xorg (Score:1, Informative)
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.
Re:How much more 'silent' was than other bugs? (Score:5, Informative)
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).
I think that's a weird attitude but that's what we've got.
Re:What I suggest to people (Score:5, Informative)
Actually, MacOS uses the Mach microkernel in a BSD system; some code was taken from FreeBSD -- but not the kernel.
Re:Convenient (Score:5, Informative)
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.
Re:What I suggest to people (Score:5, Informative)
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.
Re:Convenient (Score:3, Informative)
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.
Re:Blame Xorg (Score:5, Informative)
Yep.
On Linux input devices are now moved into the kernel. The only complex thing remaining is modesetting and hardware acceleration. But they are being fixed as well.
In fact, you can run 'rootless X' on Fedora ( http://lwn.net/Articles/341033/ [lwn.net] ) and soon on Ubuntu ( https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-maverick-rootless-x [launchpad.net] ). Here 'rootless' means that the server doesn't require root privileges to work.
Re:Convenient (Score:2, Informative)
Oh god they're countless. Sure, the publicly known privilege escalations are patched now, but there are a few that were around for many many years.
The old NT login bug was there for a long time before MS fixed it.
Re:How much more 'silent' was than other bugs? (Score:3, Informative)
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.
Re:Blame Xorg (Score:3, Informative)
Yes, it starts as root, but then it immediately drops privileges upon initialization.
Re:How much more 'silent' was than other bugs? (Score:3, Informative)
I assume you mean /etc/cron.daily which is still around, along with its hourly, weekly, and monthly counter-parts.
Re:Convenient (Score:5, Informative)
Contrary to the headline written by an idiot, this isn't an Xorg bug. It's a kernel bug that can be exploited through Xorg.
Modus operandi (Score:1, Informative)
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.
Re:Convenient (Score:3, Informative)
1) http://blogs.pcmag.com/securitywatch/2010/08/unpatched_vulnerability_in_all.php [pcmag.com]
2) http://www.zdnet.com/blog/security/microsoft-warns-of-serious-unpatched-windows-7-flaw/6474 [zdnet.com]
3) http://blogs.pcmag.com/securitywatch/2010/08/unpatched_vulnerability_in_all.php [pcmag.com]
4) http://www.computerworld.com/s/article/9176944/Microsoft_warns_of_bug_in_64_bit_Windows_7?source=rss_security [computerworld.com]
5) http://isc.sans.edu/diary.html?storyid=8023 [sans.edu]
6) http://news.cnet.com/8301-1009_3-10170962-83.html [cnet.com]
7) http://www.geek.com/articles/chips/17-year-old-unpatched-windows-vulnerability-discovered-20100120/ [geek.com]
8) http://arstechnica.com/microsoft/news/2010/03/exploits-of-unpatched-ie6-ie7-flaw-on-the-rise.ars [arstechnica.com]
9) http://www.h-online.com/security/news/item/Several-known-vulnerabilities-to-remain-unpatched-on-forthcoming-Microsoft-patch-day-947191.html [h-online.com]
10) http://www.myce.com/news/microsoft-confirms-windows-shortcut-zero-day-exploit-32107/?utm_source=myce&utm_medium=frontpage&utm_campaign=related_posts [myce.com]
There, 10 vulnerabilities, which either took Microsoft months after visibility to patch, or still aren't patched.
Now, STFU.
Re:Modus operandi (Score:3, Informative)
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.
Re:Blame Xorg (Score:3, Informative)
It does nothing. No one used startx for many years by now.
Actually, quite a few people running "hacker" distros (Gentoo, Arch etc) prefer to boot into console and do startx from there when (and if) needed.
Re:Running X as root? (Score:4, Informative)
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.
Re:What I suggest to people (Score:1, Informative)
XNU is a hybrid kernel. It's part microkernel part monolithic. The big difference is how memory allocation is handled. XNU does use message passing for system calls so that aspect still exists.
As for commercial operating systems, there are several that use microkernel or hybrid kernels besides Mac OS including Windows and QNX.
Re:2 Months is Acceptable? (Score:3, Informative)
Microsoft has thousands of programmers working full-time; Linux is maintained by volunteers, working in their spare time.
False. The majority of work on Linux is done by fulltime employees of companies like Red Hat.
Open Source Workdays (Score:3, Informative)
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.