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

[spender () grsecurity net (Brad Spengler)]

> I was very busy at the time and had no chance to reply until now.

I have a different theory on this, given the suspicious timing of your 
post:
You see my recent post on DD
You click the RH magazine link
You note in my first comment:
"To rephrase, I know you.ve seen the exploit (Steve Grubb was 
suspiciously silent on the list after posting of the exploit, and I know 
he's talked to other individuals in the security community about it), 
you're just knowingly giving your users a false sense of security."

Both you and I know the discussions you've been having with others in 
the 2 months following my posting, and realize that your absence in the 
thread was indeed "suspicious," so to make it appear as though I wasn't 
right on every single point I laid out, you limp in with your reply now 
two months later.  I think this is much more accurate since it's clearly 
false given what both you and I know that you "haven't had a chance to 
reply until now."

> Brad, thanks for pointing this out. I had heard rumors of an exploit that 
> could turn selinux off last year. I theorized what could be attacked and saw 
> that your exploit attacks exactly what I thought...a variable used for yes/no 
> decisions. So, I was happy that this was all you had found.

The problem is there's nothing you can do about my attack, so I'd 
restrain your happiness a bit there, now that anyone can plug the code 
into their exploit.  It would have been better if it were an actual bug 
-- that you could fix.

> It looks to me like you have the same exact attack point that selinux does. 
> Its just that one needs to loop through them to shut them down. Wouldn't you 
> agree on that point?

It's absolutely true.  But we also don't make diagrams like those found 
in that recent RH magazine article, nor do we talk about "proven models" 
and "information flow graphs" since I've made it clear many times that 
these are pointless when your kernel is compromised.  But as I'll talk 
about a little more below, the bug I exploited to disable SELinux was 
unexploitable with grsecurity due to the UDEREF feature of PaX.

> Who says that all apps people run come from Red Hat?

Good, so now we have the problem of 3rd party apps, where you claim that 
someone can develop a policy from a black box system that wouldn't allow 
any kind of trojan activity.  You base this on an administrator 
"seriously considering whether the app needs the access or not," which 
is a complete side-step of the issue.  Administrators aren't as smart as 
you think they are.  If you happen to be in the situation of developing 
a policy for a trojaned binary, chances are you've already lost the 
game.  Kernel exploits have the notorious knack of having little to do 
with whether the binary can write to /etc/shadow or not.

> I was going to point out to Rodrigo that learning systems can encapsulate bad 
> program behavior. There have been many times SE Linux has pointed out leaked 
> descriptors, unusual memory access requests, or otherwise insecure 
> programming. We have worked in every case to fix the code upstream rather 
> than write rules for questionable code.

Good, so any of these kinds of problems have been fixed.  Thanks to this 
work, we won't have problems with questionable policies being generated 
(which an administrator is always able to review and is much easier to 
do in our RBAC system)

> You don't need the source to write policy.

You can write a policy, but it won't be good.  How do you magically 
predict future behavior of a blackbox application?  Again you side-step 
the issue.

> Any kernel vulnerability could have security consequences on any kernel. You 
> don't know until its reported, tested, and fixed.

Here you're completely wrong (again).  In the case of my previous 
exploit, that particular kernel vulnerability or any in its class cannot 
be exploited on a grsecurity-enabled system with the UDEREF feature of 
PaX enabled.  It closes down this entire class of bugs.  So no, any 
kernel vulnerability doesn't necessarily have security consequences on 
any kernel.  In this case, it had consequences on systems running 
SELinux.  Also, about the attack vector of disabling the RBAC system 
(which is what I think you'd really want to target, since the other 
sysctl toggleable values there you list are only useful against non-root 
users -- not much point when you can own the kernel, right?) I think you 
will find more difficult on a grsecurity/PaX system (and when KERNSEAL 
is complete, the attack will be impossible).  For starters, you won't be 
able to execute your code located in userland as I did with my exploit.  
Since the RBAC system is enabled, the policy dictates that you won't 
have access to /boot to grab the offsets from the kernel image, and 
KERNEXEC prevents you from having arbitrary code execution in the kernel 
(with some exceptions if you have an arbitrary write bug and are able to 
modify page tables to make some executable page writable, write your 
code in there, and redirect execution to it without the system crashing 
-- a hole that KERNSEAL will fill).  You're much more likely to just 
crash the kernel in our case, since PaX adds protection to the kernel 
itself, whereas RedHat is doing nothing in this area (maybe we'll wait 6 
years like the MPROTECT reimplementation in SELinux).

> > 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. 
>
> So I have a question. If you have a fix for this vulnerability, why aren't you 
> sending it upstream?

This is not a vulnerability.  It's a class of vulnerabilities where the 
correct solution on x86 happens to involve segmentation, a solution 
which both you and I know Linus will reject regardless of its merit 
(I've had private discussion with him and he says he will flatly reject 
adding any kind of protection to the kernel that involves segmentation 
-- this is the same reason why you haven't been able to get ExecShield 
into the mainline kernel).  So because of his decision, the solution to 
the class of bugs will remain only as part of grsecurity/PaX.

You know, it's much easier (and looks better to people who know you're 
wrong) to say that you're wrong, instead of coming back 2 months later 
with poor, misinformed arguments in an attempt to save face.

-Brad

Attachment: signature.asc
Description: Digital signature

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