Linux Kernel Security (tun/net and Null Pointer Dereferences provide 4 hour encroachment via Script Fuzz)

[Lisa Kachold]

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.
Spengler announced that 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.

"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."

Demonstration of Exploit:

While technical details about this are a bit complex, generally what's
happening can be easily explained. The vulnerable code is located in
the net/tun implementation. Basically, what happens here is that the
developer initialized a variable (sk in the code snippet below) to a
certain value that can be NULL. The developer correctly checked the
value of this new variable couple of lines later and, if it is 0
(NULL), he just returns back an error. The code looks like this:

struct sock *sk = tun->sk;  // initialize sk with tun->sk
…
if (!tun)
    return POLLERR;  // if tun is NULL return error

This code looks perfectly acceptable, right?  Well, it is, until the
compiler takes this into its hands. While optimizing the code, the
compiler will see that the variable has already been assigned and will
actually remove the if block (the check if tun is NULL) completely
from the resulting compiled code. In other words, the compiler will
introduce the vulnerability to the binary code, which didn't exist in
the source code. This will cause the kernel to try to read/write data
from 0x00000000, which the attacker can map to userland – and this
finally pwns the box.

Brad was able to even bypass SELinux protections with this and LSM.

Exploit Code:  http://grsecurity.net/~spender/cheddar_bay.tgz

http://www.youtube.com/watch?v=UdkpJ13e6Z0
http://isc.sans.org/diary.html?storyid=6820&rss
http://grsecurity.net/

-- 
http://linuxgazette.net/164/kachold.html
(623)239-3392
(503)754-4452 www.obnosis.com