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

[Steve Grubb <sgrubb () redhat com>]

On Monday 14 May 2007 14:04, Brad Spengler wrote:
> > 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:

I don't think theories really matter at this point. If I said I was busy I 
was. But I've finished up my project and can now discuss this with you.

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

No, I think you hit some really good points. I just don't have the bandwidth 
to respond to every email all the time.

> > 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, 

There are likely similar attacks to the NULL ptr issue. Its just a well 
known/predictable invalid pointer dereference.

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

Super.

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

I would absolutely agree with this statement. What these graphs are supposed 
to be illustrating is that you can't even get to the point of running your 
exploit in many cases.

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

I am not familiar with UDEREF. Do you have a white paper or some discussion I 
could read to see what this is?

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

This is somewhat true. You would have to determine if the program was 
installed trojaned or became trojaned after installation. If it was installed 
trojaned, it might contain a kernel exploit and then all bets are off. If it  
was not installed with a trojan in it, there should have been a time when you 
were able to write good policy for it. 

But there are actually many things that have to happen to get a program 
trojaned. There is execshield which helps somewhat. By itself it doesn't 
solve all problems. Then there are security mechanisms in gcc to help 
discover buffer overflows and the FORTIFY_SOURCE options for glibc will also 
help checkout many of the dangerous functions. Ulrich Drepper lists much of 
this work in a paper you cited.

If someone manages to bypass all that with SE Linux policy, they could very 
well take advantage of a kernel exploit as long as they make calls allowed by 
that domain or calls in which the exploit occurs before the permission check.

The bottom line is that kernel vulnerabilities can be serious. It just really 
depends on a case by case basis.

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

Does grsecurity solve that?

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

Agreed.

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

You can write policy, run the app, see what AVCs come up, see if they sound 
reasonable, allow them, rinse and repeat as needed. There comes a point where 
you've exercised most behavior.


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

Right. And you just proved I'm not wrong. You have to test the problem. In 
your case maybe this one wasn't a problem. (But it was before you fixed it.)

> It closes down this entire class of bugs.  So no, any kernel vulnerability
> doesn't necessarily have security consequences on any kernel.

Exactly my point.

> In this case, it had consequences on systems running 
> SELinux.

And systems without.

> 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?) 

True. You could do a lot of things besides turning selinux off. 

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