SELinux continues to be proven not to work, suprised?

11 replies [Last post]
cisc0ninja's picture
SX Crew
Joined: 2008/03/17

I know this is a little late, but there is a fairly recent Remote Linux Kernel exploit out.
This has been shown to be one of the most, if not the most clean exploit ever written of it's type.
I'm probably not the best person to be describing and talking about it but from the little info I know, it has an SELinux disabling payload that basicly makes SELinux irrelevant. GRsec should in theory protect against it, but we have not fully proven this yet.
Also I believe that while this is for x64 we don't see too many reasons why it wouldn't work on x86, even if you had to tweak the code a little.
Basicly because this exploit can not be protected against very easily the entire world regarding corporate and school wise has been in an uproar about trying to patch for it even though you basically can't.
Pretty much the only way that we have found to not be susceptible to it is to be running a custom kernel that is 2.6.28.x and higher with GRsec.

Here's a little info you can find at the beginning of the code which list the main systems that are vulnerable to this exploit:

/* CVE-2009-0065 SCTP FWD Chunk Memory Corruption
* Linux Kernel 2.6.x SCTP FWD Memory COrruption Remote Exploit
* coded by: sgrakkyu
* NOTE: you need at least one sctp application bound on the target box
* Supported target:
* Ubuntu 7.04 x86_64 (2.6.20_15-17-generic / 2.6.20_17-server)
* Ubuntu 8.04 x86_64 (2.6.24_16-23 generic/server)
* Ubuntu 8.10 x86_64 (2.6.27_7-10 geenric/server)
* Fedora Core 10 x86_64 (default installed kernel)
* OpenSuse 11.1 x86_64 (default installed kernel)

You can download the code from milw0rm or packetstorm at either of the following links:[search].x=0&[search].y=0

"He who knows his own weakness, knows more of himself than he who has none."