The Linux kernel folks "silently" pushed out a patch for a critical privilege escalation bug this week. It was for a hole that could allow an attacker to execute code at the root level from any GUI application. The patch took two months after the flaw was reported on June 17, researchers say. SUSE engineers claim they originally found it, reported it and patched it in SUSE in September 2004, says the security blog The H. But the SUSE patch never made its way into the kernel at that time.

And so the hole remained in the kernel until Rafal Wojtczuk, a security researcher from Invisible Things Lab (ITL), also found it this summer while working on Invisible's Qubes project -- an open source desktop virtualization tool. On top of all that, the fix that Linus Torvalds wrote and "silently" pushed out (after it was reviewed by only one other person) on Aug. 13, was itself buggy and more fixes followed.

If that wasn't enough, the kernel group reportedly extended their deadline for disclosure about the hole. Disclosure should have happened by Aug. 1 about a month after the org got the info from X.org. The kernel org says the bug has now been addressed in versions 2.6.27.52, 2.6.32.19, 2.6.34.4 and 2.6.35.2 of the kernel. It is now up to the distro makers to push the fix out to their users.

A few days after the patches were safely pushed out in a new kernel release, the ITL security researchers could at last disclose the problem. One of them, well respected security researcher Joanna Rutkowska, wrote in her blog on Tuesday:

"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. The attack allows even to escape from the SELinux's "sandbox -X" jail. To make it worse, the attack has been possible for at least several years, most likely since the introduction of kernel 2.6."

However, security researchers have their own reasons for playing up the bugs they find. So I asked an independent third party, kernel expert Jonathon Corbet, editor of LWN.net. He agreed with me that a two-month delay wasn't good (much less six years). But he downplayed the seriousness of the hole itself. In an e-mail exchange he told me, "I believe that two months is longer than we should take to fix a vulnerability of this type. But I really don't know why it took that long and don't really want to criticize people too badly. I would point out that this is the kind of bug that requires an attacker to already have compromised the system far enough to be able to run code locally; this vulnerability cannot, in and of itself, give a remote attacker any sort of access to a vulnerable system. That's why the [researcher's] article mentions things like PDF exploits."

He further explained, "So, to exploit the bug, an attacker must (1) target a system containing this particular vulnerability - most server configurations probably do not run user-accessible X, (2) find *another* vulnerability on that system which is exploitable, say, via a malicious PDF file, (3) transmit that file to the target user, and (4) get the user to view it on the target system. This is not implausible; word is that the Google China compromises were done in a way similar to this. But it's a nontrivial and challenging attack that is not going to lead to widespread compromises across the net."

Despite Corbet's reassurances, opinions range among experts as to how serious the hole is (per comments on Rutkowska's blog post and an article on LWN.net that stemmed from my questions on the matter). Red Hat rated it as an urgent priority and kernel developer Greg Kroah-Hartman told the Linux masses in no uncertain terms terms:: "All users of the 2.6.35 kernel series must upgrade."

Bugs happen -- even root-level bugs. But fair is fair. Microsoft repeatedly gets beaten up if it takes two months to fix a known, critical bug, much less six years. Even if you give the kernel org credit that for some reason the SUSE bug report fell through the cracks, Wojtczuk's paper points out that a previous researcher had given a presentation [PDF] about the problem in 2005. The PDF is still on the Internet and includes a diagram about the hole in Linux 2.6. And as of this week Wojtczuk's proof-of-concept paper [PDF] is out in the wild, too.

Torvalds infamously has a policy of not describing the security impacts of patches for Linux vulnerabilities. A bug is "disclosed" by publishing the code, but not in the commit message. He thinks that "script kiddies" could be helped to more easily exploit flaws pointed out to them. Perhaps he's right on that count, but the world of hacking has changed a lot over the years. With big money at stake, the people breaking into machines aren't just script kiddies, they are every bit as brilliant as the people protecting the machines.

What that means is that the only ones that don't know about a known hole is the user.

Corbet doesn't exactly defend the policy, but does explain the rationale for it. He says, "The 'silently patched' part of [The H's] article is a common criticism of the kernel process. It's not 100% without merit, but the kernel developers take the approach that (1) a large proportion of kernel bugs are, by the nature of kernel programming, security-related and we can't sound the red alert every time, and (2) it's up to the distributors to get fixes to their users. In a case like this, the distributors will have been well aware of the problem before the fix went out, so there was no real need to start ringing bells."

Now that Linux has made its way onto the production machines of just about every large business in the western world, Linux will become an ever bigger target for professional hackers not just script kiddies. It is time the keepers of the kernel evaluate their disclosure policies. There's a fine line between trying to keep information away from the bad guys and using that policy as an excuse to cover up your own mistakes.