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.'"
Blame Xorg (Score:5, Interesting)
Re:Blame Xorg (Score:5, Interesting)
That should be fixed eventually. With the switch to kernel modesetting (already happening) there shouldn't be any need for X to mess directly with hardware anymore, and without that it should run just fine without root privileges.
Re:How much more 'silent' was than other bugs? (Score:3, Interesting)
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!
Re:Convenient (Score:3, Interesting)
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.
Re:Convenient (Score:3, Interesting)
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.
Re:How much more 'silent' was than other bugs? (Score:2, Interesting)
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.
Re:Is this news? (Score:2, Interesting)
Quickly? This flaw has existed for 7 years.
Re:How fancy can you get? (Score:3, Interesting)
Re:Convenient (Score:4, Interesting)
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/ [mach-nine.com] (under construction now?), http://www.lomag.net/information/news.php [lomag.net]
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.
Root in the kernel == game over (Score:3, Interesting)
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.
Ad hominem (Score:5, Interesting)
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?
Re:Convenient (Score:2, Interesting)
Re:What I suggest to people (Score:4, Interesting)
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.
Re:Root in the kernel == game over (Score:3, Interesting)
int vfs_mkdir(struct inode *dir, struct dentry *dentry, int mode)
{
int error = may_create(dir, dentry, NULL);
if (error)
return error;
if (!dir->i_op || !dir->i_op->mkdir)
return -EPERM;
mode &= (S_IRWXUGO|S_ISVTX); //line 1883
error = security_inode_mkdir(dir, dentry, mode);
if (error)
return error;
DQUOT_INIT(dir); // line 1887
error = dir->i_op->mkdir(dir, dentry, mode);
if (!error)
fsnotify_mkdir(dir, dentry);
return error;
}
Line 1874 is the "old" permission check.
Line 1883-1885 is actually the SELinux hook. Note how this is a restrictive model rather than an authoritative model, i.e. it doesn't encapsulate the operation. It merely checks to see if you are allowed to perform the operation before proceeding with the very same arguments which were passed to the function (e.g. dentry
Line 1887-1888 is the weak spot. If I were an attacker who passed the "dentry" structure to this function I could still hold a reference to that structure. And holding the reference, I can overwrite the memory. If I time my memory write correctly (easier to do on a multi-core processor where I'm not even required to preempt the first call) I can inject my own parameters *after* the security checks. In this case I can create new directories wherever I want.
Remember, this is *not* something I claim you can do from userspace (haven't investigated that), but from within the kernel this is entirely possible!
I fully expect Windows to be vulnerable to similar attacks from within the kernel.
My gripe is how SELinux is expected to be able to confine malicious code which is already executing inside the kernel. It is a speed bump at best. Code running inside the kernel can modify all writable memory. Certainly it can modify memory it allocated itself.
Note, this is not an attack which is made possible by running as root. You need to be running in kernel - and then it doesn't really matter whether you run as root or not.