On exploiting null ptr derefs, disabling SELinux, and silently fixed Linux vulns

[spender () grsecurity net (Brad Spengler)]

Re:[Dailydave] Is Windows Integrity Control in Vista really worth the
performance hit? And does it really work?

I'd like to comment on a couple things.  Also, if there are any security
historians on the list, I submit for your record-keeping what I believe
to be the first public exploit for a null ptr dereference bug in the
Linux kernel.  It was developed in a matter of hours on August 10th,
2006.  The bug has been fixed and the bug class has been leaked by ilja
(though PaX already had added complete protection from the bug class
months before ilja's leak ;)), so the only purpose of releasing this is
to insert that seed of doubt into SELinux users who buy into the
"information flow graph" and "proven security model" propaganda.

The URL for the exploit:
http://grsecurity.net/~spender/exploit.tgz

Full details about the exploit are in the README file in the tarball.
For the curious, the vulnerable versions of Linux were 2.6.17->2.6.17.6

Now on to the comments:
1) Re: "Any kernel exploit that allows writing to arbitrary kernel
memory can potentially defeat any kernel protection mechanism."
(sgrubb () redhat com)

Now that anyone can plug my SELinux-disabling function into their kernel
exploit, I'd like all RedHat employees to stop using "potentially" in
any similar sentence from now on.  The heuristics are generic enough to
have allowed the exploit to work on a custom-compiled kernel as well as
the default kernel in Fedora Core 6 Test 1.  Did I also mention it
disables all other LSM modules as well, atomically?

2)  If anyone wants to waste some time finding out the answer to this
question, I'd be interested in knowing what other distribution kernels
were/are still vulnerable to that bug.  The reason I ask this is because
the bug was fixed silently with only a "splice: fix problems with
sys_tee()" changelog, even though the submitter of the patch knew it to
be a local DoS (but still oblivious to the exploitability of this class
of bugs, particularly in this case).  For kicks, you can read the LKML
thread here:
http://lkml.org/lkml/2006/7/7/34

3) Re: "I can only guess that you mean systems that learn normal
behavior so that abnormalities can be spotted? The problem is how do you
_know_ you are observing correct behavior. You could have a trojaned app
that you are now learning its behavior."
(sgrubb () redhat com)

If I'm downloading signed updates from RedHat that are trojaned, I think
I have more of a problem than learning on my hands.  So that can't be
the problem.  What about third-party apps then for which there exist no
SELinux policy?  I think you severely overestimate the intelligence of
most administrators in their ability to determine at such a low level
what kind of access a program needs to the system.  Is each
administrator then required to completely audit the source of all apps
for which no policy exists?  What if no source is available?  Is
every administrator supposed to be an expert in IDA Pro and
unpacking? People don't learn the app's behavior, administrators don't
have time when customers are complaining: they disable SELinux.

There's a reason why SELinux is still around.  The users clearly
haven't asked for something of this complexity and unusability.  When
you have an unworkable "solution" to a problem, there's lots of
money to be made in making it workable. (The fact that there even exists
a company like Tresys is proof of this.)

Unrelated, but while I'm here:
4) Some of you may have seen a "toto toto" individual posting on FD
recently about selling grsecurity exploits.  I contacted the person and
was able to obtain his "vulnerability."  It involved the RBAC policy
loading code, only accessible to fully-privileged root users, and was
not even a bug.  The amateur auditor didn't know the semantics of
strnlen_user (it returns the length of the string, including the null
character) and assumed there was a non-null termination bug (which was
then "somehow" exploitable ;))

In summary: SELinux's guarantees aren't worth as much as they claim to
be, Linux has lots of null pointer dereference bugs and some of them are
exploitable, intentionally silently fixing a security bug has been
demonstrated in the Linux kernel, and grsecurity/PaX is the only thing
in any OS that will protect you against invalid userland dereference bugs
(of which null ptr dereference bugs are a subset), unless you're using
some arch like sparc64.  PaX is also still the only project that
focuses at all on preventing kernel exploits as well with its
KERNEXEC (and soon, KERNSEAL) feature.  Expect OpenBSD to independently
invent a protection against null ptr deref bugs sometime in 2009.

I'll reply to any legitimate mails off-list (I don't receive mails
from the list).

Enjoy your weekend!

-Brad

Attachment: signature.asc
Description: Digital signature

_______________________________________________
Dailydave mailing list
Dailydave () lists immunitysec com
http://lists.immunitysec.com/mailman/listinfo/dailydave