Distribution security response times

Two high-profile kernel bugs—with publicly released exploits—have recently been making news. Both can be used by local attackers to gain root privileges, which makes them quite dangerous for systems that allow untrusted users to log in, but they might also be used in conjunction with other flaws to produce a remote root exploit. They are, in short, just the kinds of vulnerabilities that most system administrators would want to patch quickly, so a look at how distributions have responded seems warranted.

The vulnerabilities lie in the x86_64 compatibility layer that allows 32-bit binaries to be run on 64-bit systems (see the Kernel page article for more details). In particular, that code allows 32-bit programs to make system calls on a 64-bit kernel. One of the bugs, CVE-2010-3301, was reintroduced into the kernel in April 2008, seven months after being fixed as CVE-2007-4573. The second, CVE-2010-3081, was discovered in the process of finding the first, and had been in the kernel since 2.6.26, which was released in July 2008.

Obviously, these are long-standing kernel holes that may have been available to attackers for as long as two-and-a-half years. In fact, a posting on the full-disclosure mailing lists claims that CVE-2010-3081 was known by a shadowy group called "Ac1db1tch3z" since the code causing the bug was committed in April 2008. Included in the post was a working exploit.

Ben Hawkes found and reported both of the vulnerabilities and fixes for both were quickly committed to the mainline kernel. Both were committed on September 14, but it is clear that at least CVE-2010-3081 was known a week earlier. Stable kernels were released on September 20, and some distributions had fixes out on September 17.

While enterprise kernels (e.g. RHEL, SLES) tend to be based on fairly old kernels (RHEL 5 is 2.6.18-based, while SLES 11 is 2.6.27-based), the distributors often backport features from newer kernels. Unsurprisingly, that can sometimes lead to backporting bugs along with the features. For RHEL, that meant that it was vulnerable to CVE-2010-3081 even though that code came into the kernel long after 2.6.18. On September 21, Red Hat issued updates for RHEL 5 and 5.4 to fix that problem. CentOS, which necessarily lags RHEL by at least a few hours, has a fix for CVE-2010-3081 available for CentOS 5 now as well.

For SLES, the situation is a little less clear. Based on its kernel version, it should be vulnerable to both flaws, but no updates have been issued as of this writing. In a separate advisory on September 21, SUSE noted (in the "Pending Vulnerabilities ..." section) that it was working on fixes for both.

For the more community-oriented distributions (Debian, Fedora, openSUSE, Ubuntu, and others), the response has been somewhat mixed. Ubuntu, Debian, and Fedora had fixes out on September 17 for both bugs (or, in the case of Debian, just one, as its stable distribution ("Lenny") is based on 2.6.26 and thus not vulnerable CVE-2010-3301). openSUSE has yet to release a fix and none of the secondary distributions that we track (Gentoo, Mandriva, Slackware, etc.) has put out a fix either.

How quickly can users and administrators expect security fixes? The enterprise vendors, who are typically more cautious before issuing an update, took a week or more to get fixes in the hands of their users. Meanwhile, exploits have been published and have been used in the wild. That has to make a lot of system administrators very nervous. Those running SUSE-based systems must be even more worried. A one-week delay (or more depending on where you start counting) may not seem like a lot of time, but for critical systems, with lots of sensitive data, it probably seems pretty long.

Local privilege escalation flaws are often downplayed because they require a local user on the system to be useful. But that thinking has some flaws of its own. On even a locked-down system, with only trusted users being able to log in, there may be ways for local exploits to be turned into remote exploits. Compromised user accounts might be one way for an attacker to access the system, but there is a far more common route: network services.

One badly written, or misconfigured, web application, for example, might provide just the hole that an attacker needs to get their code running on the system. Once that happens, they can use a local privilege escalation to compromise the entire system—and all the data it holds. Since many servers sit on the internet and handle lots of web and other network traffic, compromising a particular, targeted system may not be all that challenging to a dedicated attacker. Using a "zero day" vulnerability in a widely deployed web application might make a less-targeted attack (e.g. by script kiddies) possible as well.

While most of the "big four" community distributions were quick to get out updates for these problems, they still left a window that attackers could have exploited. That is largely unavoidable unless there were embargoes enforced on sensitive patches flowing into the mainline kernel—something that Linus Torvalds has always been opposed to. Then, of course, there is the (much larger) window available to those who closely track kernel development and notice these bugs as they get introduced.

That is one of the unfortunate side-effects of doing development in the open. While it allows anyone interested to look at the code, and find various bugs—security or otherwise—it does not, cannot, require that those bugs get reported. We can only hope that enough "white hat" eyes are focused on the code to help outweigh the "black hat" eyes that are clearly scrutinizing it.

For distributors, particularly Red Hat and Novell, it may seem like these flaws are not so critical that the fixes needed to be fast-tracked. Since there are, presumably, no known, unpatched network service flaws in the packages they ship, a local privilege escalation can be thwarted by a more secure configuration (e.g. no untrusted users on critical systems). While true in some sense, it may not make those customers very happy.

There are also plenty of systems out there with some possibly untrusted users. Perhaps they aren't the most critical systems, but that doesn't mean their administrators want to turn them over to attackers. It really seems like updates should have come more quickly in this case, at least for the enterprise distributions. As we have seen, a reputation for being slow to fix security problems is a hard one to erase; hopefully it's not a reputation that Linux is getting.