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
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
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
first, and had been in the kernel since 2.6.26, which was released in July
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
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
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
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:
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
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
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"
focused on the code to help outweigh the "black hat" eyes that are clearly
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
is a hard one to erase; hopefully it's not a reputation that Linux is getting.
to post comments)