Clever attack exploits fully-patched Linux kernel
'NULL pointer' bug plagues even super max versions

A recently published attack exploiting newer versions of the Linux kernel is getting plenty of notice because it works even when security enhancements are running and the bug is virtually impossible to detect in source code reviews.

The exploit code was released Friday by Brad Spengler of grsecurity, a developer of applications that enhance the security of the open-source OS. While it targets Linux versions that have yet to be adopted by most vendors, the bug has captured the attention of security researchers, who say it exposes overlooked weaknesses.

Linux developers "tried to protect against it and what this exploit shows is that even with all the protections turned to super max, it's still possible for an attacker to figure out ways around this system," said Bas Alberts, senior security researcher at Immunity. "The interesting angle here is the actual thing that made it exploitable, the whole class of vulnerabilities, which is a very serious thing."

The vulnerability is located in several parts of Linux, including one that implements functions known as net/tun. Although the code correctly checks to make sure the tun variable doesn't point to NULL, the compiler removes the lines responsible for that inspection during optimization routines. The result: When the variable points to zero, the kernel tries to access forbidden pieces of memory, leading to a compromise of the box running the OS.

The "NULL pointer dereference" bug has been confirmed in versions 2.6.30 and 2.6.30.1 of the Linux kernel, which Spengler said has been incorporated into only one vendor build: version 5 of Red Hat Enterprise Linux that's used in test environments. The exploit works only when a security extension knows as SELinux, or Security-Enhanced Linux, is enabled. Conversely, it also works when audio software known as PulseAudio is installed.

An exploitation scenario would most likely involve the attack being used to escalate user privileges, when combined with the exploitation of another component - say, a PHP application. By itself, Spengler's exploit does not work remotely.

With all the hoops to jump through, the exploit requires a fair amount of effort to be successful. Still, Spengler said it took him less than four hours to write a fully weaponized exploit that works on 32- and 64-bit versions of Linux, including the build offered by Red Hat. He told The Register he published the exploit after it became clear Linus Torvalds and other developers responsible for the Linux kernel didn't regard the bug as a security risk.

"By the time I wrote the exploit, there was a fix floating around, but it didn't look like it was going to be going into any of the stable releases," he said. "It was just a trivial 'oops' instead of something that could give you arbitrary code execution in the kernel."

Comments that accompany Spengler's exploit code go on to detail statements Torvalds and other developers are said to have made in group emails discussing the bug.

"That does not look like a kernel problem to me at all," Torvalds is quoted as saying in one message. "He's running a setuid program that allows the user to specify its own modules. And then you people are surprised he gets local root?"

On that front, at least one security researcher agreed with the Linux team.

"Setuid is well-known as a chronic security hole," Rob Graham, CEO of Errata Security wrote in an email. "Torvalds is right, it's not a kernel issue, but it is a design 'flaw' that is inherited from Unix. There is no easy solution to the problem, though, so it's going to be with us for many years to come."

The larger point, Spengler said, is that the Linux developers are putting users at risk by failing to clearly disclose when security vulnerabilities have been discovered.

"Why is it that whenever there is an exploitable vulnerability in Linux, it's described as a denial of service?" he said. "It kind of makes the vendors think the security is better than it actually is."

Wherever the fault may lie, the potential damage is very real.

"It's not going to light the world on fire, but it is a very subtle bug and solid exploit," said Ed Skoudis, founder and senior security consultant for InGuardians. "The real story here is how subtle it is, and that the compiler itself introduced it during code optimization."

So far, Torvalds and company have yet to respond to the disclosure. We'll be sure to update this story if they do. ®

It's a very interesting bug. It's amazing what the compiler will do to your code!

How on earth are you supposed to predict or debug things like that?