New Linux Flaw Enables Null Pointer Exploits

win32sux · 07-18-2009, 09:24 AM

I refrained from posting this in the Kernel Vulns thread earlier, due to its zero-day status. But now that the issue has been Slashdotted, there's no use in keeping us from publicly discussing this vulnerability. The link to the article (from which I quote below) is here. Brad Spengler's original announcement on the Dailydave mailing list is here.

Quote:

A researcher has published exploit code for a new vulnerability he discovered in the Linux kernel. The vulnerability is an especially interesting one in that the researcher who discovered it, Brad Spengler, has demonstrated that he can use the weakness to defeat many of the add-on security protections offered by SELinux and AppArmor.

{BBI}Nexus{BBI} · 07-18-2009, 12:47 PM

Read about this on the Register. In that report he claims it took him less than 4 hours to write an exploit.

Quote:

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.

In the article you point to it says 2 hours.. Somewhere between the two there's the true facts. Aparrently Linus says this is not a kernel problem but something inherited from Unix.

win32sux · 07-18-2009, 01:13 PM

What I find amazing is the role which the compiler plays in this.

As someone in the Slashdot discussion said, this is literally a GNU/Linux vulnerability.

GazL · 07-18-2009, 02:30 PM

Quote:

Originally Posted by win32sux

What I find amazing is the role which the compiler plays in this.

It is an interesting one isn't it. Though to be fair to the compiler, it looks like bad code caused it to make a bad decision.

Here's the code in question:

Code:

struct sock *sk = tun->sk; // initialize sk with tun->sk

if (!tun)
        return POLLERR; // if tun is NULL return error

If there's a possibility of tun being NULL then initialising *sk from it before checking for NULL is clearly a dubious operation regardless of whether you check it afterwards.

Surely it's common sense that you should check it before you use it.

Code:

if (!tun)
        return POLLERR; // if tun is NULL return error

struct sock *sk = tun->sk; // initialize sk with tun->sk

But then, I'm just a novice C coder, so I may be missing something in the details.

Robhogg · 07-19-2009, 03:26 PM

From the SANS Internet Storm Center:

Quote:

Source code for a exploit of a Linux kernel vulnerability has been posted by Brad Spengler (Brad is the author of grsecurity). I have to tell you right now – this was one of the most fascinating bugs I've read about lately.

Why is it so fascinating? Because a source code audit of the vulnerable code would never find this vulnerability (well, actually, it is possible but I assure you that almost everyone would miss it). However, when you add some other variables into the game, the whole landscape changes. more...

No update down the pipeline from Debian yet...

Updated to add:
Sorry, just noticed the sticky thread on this subject

win32sux · 07-19-2009, 03:37 PM

Quote:

Originally Posted by Robhogg

Sorry, just noticed the sticky thread on this subject

No problem, I've merged your post into the sticky.

win32sux · 07-19-2009, 03:42 PM

Quote:

Originally Posted by Robhogg

No update down the pipeline from Debian yet...

What about upstream? Has anyone heard anything? Or are they still pointing fingers at each other?

GazL · 07-21-2009, 04:53 AM

It's in 2.6.27.27 and also in .30.2 by the looks of it.

win32sux · 07-28-2009, 03:59 PM

Ubuntu issued USN-807-1 today, yet no mention of CVE-2009-1897. What's up with that?

EDIT: Nevermind, not even the latest Ubuntu release (at the time of this post) uses a 2.6.30.y kernel.

win32sux · 07-30-2009, 10:12 PM

Thread unstickied (we've given it enough airtime). Replying to reset decay.