Responding to the kernel ELF vulnerability

Did you know...?

LWN.net is a subscriber-supported publication; we rely on subscribers to keep the entire operation going. Please help out by buying a subscription and keeping LWN on the net.

May 18, 2005

This article was contributed by Joe 'Zonker' Brockmeier.

Paul Starzetz has discovered a vulnerability in the Linux kernel that can be used to gain root access to the system. The vulnerability, published on May 11, affects the kernel's ELF (Executable and Linking Format) loader, which could allow a local user to use a manipulated binary to gain elevated privileges.

This vulnerability affects kernels in the 2.2, 2.4 and 2.6 series. According to Starzetz report, the flaw is in the function elf_core_dump(), in binfmt_elf.c. This function does not correctly handle the argument area of the ELF process, which could be abused to override the memory layout:

It is possible to create a manipulated ELF binary, that specifies an ELF program section to be loaded at the place of program arguments, but with no access rights itself (that is, a page table level protection equal to PROT_NONE). That will cause the strnlen_user() function to page fault at the first attempt to count argument lengths. Moreover, the loading of ELF sections happens just after the initial arguments have been set up in the fresh memory space, so that it is easily possible to "override" the predefined ELF memory layout. To illustrate this, here two memory layouts:

(1) initial ELF memory layout before starting to load program sections:

----------------EMPTY------------------[ ARGS stack region ] TASK_SIZE


(2) possible memory layout after loading ELF sections:

---------[CODE][DATA]------------------[FAKE][stack region ] TASK_SIZE

where FAKE is an ELF section mmaped into memory with PROT_NONE rights specified.

What seems odd is the amount of attention that the vulnerability is getting, or the lack thereof. While Colin Percival's report of a vulnerability in Hyper-Threading is getting attention, the ELF vulnerability has barely been a blip on the radar.

To date, only Trustix has issued an alert and fix for this issue. Red Hat has just issued a kernel update, but the ELF vulnerability is not mentioned in the release announcement. We've checked the lists for Ubuntu, Debian, Mandriva, Slackware, Fedora, Fedora Legacy, Yellow Dog -- none of these distributions have issued a update yet for what appears to be a fairly serious local exploit. As of this writing, nearly a week has passed since Starzetz made the discovery public.

At the same time, most of those vendors have released new versions of Squid to deal with a vulnerability that would allow malicious users to spoof DNS lookups. The Squid vulnerability was announced the same day as the ELF loader vulnerability.

It does seem that a patch, at least for the 2.6 series, is available. Given the potential severity of the vulnerability, we're curious to see how long it will be before updates are made available from the major distributions. With Linux under close scrutiny for security vulnerabilities and vendor response times, one hopes that it will be soon.

(Log in to post comments)

Responding to the kernel ELF vulnerability

Posted May 19, 2005 2:35 UTC (Thu) by mattdm (subscriber, #18) [Link]

There is an update for FC3 in the "testing" area which covers this.

test kernel for RHEL 4, too

Posted May 19, 2005 6:41 UTC (Thu) by barryn (subscriber, #5996) [Link]

2.6.9-10, available at:
http://people.redhat.com/davej/kernels/RHEL4/

Responding to the kernel ELF vulnerability

Posted May 19, 2005 10:29 UTC (Thu) by NightMonkey (subscriber, #23051) [Link]

And for Gentoo's 2.6 series: http://dev.gentoo.org/~dsd/gentoo-dev-sources/releases.htm
(See 2.6.11 patchset, release 12)

Of course, 2.6 isn't vulnerable, as seen from gregkh's comment... ;)

Can't seem to find a GLSA to go with this release, but perhaps I need to look harder?

Responding to the kernel ELF vulnerability

Posted May 19, 2005 4:18 UTC (Thu) by gte223j (guest, #6492) [Link]

You could always mount /home as noexec and the same goes for /tmp ....... system binaries only:-0

2.6 isn't vulnerable

Posted May 19, 2005 6:13 UTC (Thu) by gregkh (subscriber, #8) [Link]

The main reason there have not been any updates, is that there really isn't
a problem for the 2.6 kernel. The original author has admited this finally,
no one was ever able to reproduce it on a 2.6 kernel. The only reason I
released a kernel update, was at the time, we thought there was an
off-chance that there was a problem. However in further testing, it has not
been the case.

But the patch was a good one to have, to prevent any other types of this
kind of error in that same area, if some other attack vector like the
reported one were developed.

2.6 isn't vulnerable

Posted May 19, 2005 6:59 UTC (Thu) by komarek (guest, #7295) [Link]

Comments and content like this from gregkh, are why I pay for and read LWN. How many slashdot posts would I have to read to get the same information, with the same confidence? Thanks corbet and gregkh for keep us all in-the-know.

2.6 isn't vulnerable

Posted May 19, 2005 7:22 UTC (Thu) by jhs (guest, #12429) [Link]

I actually specifically clicked on the comments just to post a similar message about the LWN content. So I guess I will put it here. The LWN kernel section is excellent.

Responding to the kernel ELF vulnerability

Posted May 20, 2005 22:58 UTC (Fri) by giraffedata (subscriber, #1954) [Link]

That will cause the strnlen_user() function to page fault at the first attempt to count argument lengths.

So? How does that get you to

could allow a local user to use a manipulated binary to gain elevated privileges.

Responding to the kernel ELF vulnerability

Posted May 23, 2005 20:30 UTC (Mon) by gswoods (subscriber, #37) [Link]

Today the Fedora project released a kernel update that claims to fix CAN-2005-1263, the ELF vulnerability.