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

[spender () grsecurity net (Brad Spengler)]

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

The attack I was referring to was the SELinux disabling, not the kernel 
exploit which allowed me to disable SELinux, although it is also since it's 
highly unlikely that PaX's UDEREF will be implemented in Fedora/RHEL there 
will be nothing you can do about the class of bugs you mention either.

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

While in cases where the vulnerable code is in some rarely used driver or 
service of the OS which SELinux denies access to (before the vulnerable 
code is reached), in other cases no unusual access is needed to the system.  
A remote attacker doesn't need to force apache to write out a binary and 
execute it.  In the case of my exploit, only the creation of an anonymous 
read/write mapping at a fixed address was necessary since the kernel 
executed the code in it.  SELinux doesn't/can't prevent this and this can 
be done remotely.

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

As noted in another mail, since you've already looked at the grsec source, 
you could have searched for UDEREF and found its configuration help.

> This is somewhat true. You would have to determine if the program was 
> installed trojaned or became trojaned after installation.

In a grsec system, the program wouldn't have arbitrary code execution and 
wouldn't be allowed to be written to/replaced except by an authenticated 
administrator.  This effectively only leaves the case of the program being 
installed trojaned, and then as you said yourself all bets are off.

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

It changes the question around to let the administrator specify which 
resources are important to them.  Then, during full system learning, 
policies are automatically generated such that untrusted processes can't 
access the specified resources.  The learning system automatically forms a 
list of these things, including use of capabilities, socket usage, and 
access to files.  It performs intelligent reduction to reduce the chance 
that the policy will need to go through several iterations of revision to 
match normal behavior, while at the same time enforcing a secure base in 
each generated policy to ensure that the reduction process doesn't affect 
security greatly.  The intelligent learning is done on several different 
levels.  It creates roles for user accounts that are used.  If a given 
user only logs in to his account from a single IP, the role for that user 
is restricted to logins from that IP.  It's further reduced to larger 
subnets if connections are made from different subnets.  This is done 
automatically, and services like apache will have their role reduced to 
allowing connections from any IP.  I've found that the auto-generated 
policies are more secure than policies developed by administrators (unless 
they go above the granularity provided by the learning system and include 
things like nested subjects).

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

This seems incredibly time consuming, and in my experience the number of 
apps that request more access than they need is very small and the access 
is in general not important.  In both cases, whether a program or an 
administrator decides, you may end up allowing something that shouldn't in 
these rare cases.  Assuming an intelligent administrator is an error.  
Taking them out of the equation and automatically generating the policy 
has produced better results in my experience.  And since the problems you 
find in applications are fixed upstream, it's not something auto-learners 
have to worry about.  Why put the responsibility on all the users which 
can be done higher up on the chain?

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

I'm not sure how you came to that conclusion.  We didn't have to test 
anything since the bug was of a specific class that UDEREF generically 
protects against (which is clearly visible by the changelog/bug report).  
UDEREF was developed prior to this vulnerability, so we had nothing to 
fix either.  We were already protected against exploitation of the bug, 
while systems without UDEREF were not.  These two situations seem very 
different to me; how can you claim they're the same?  It has nothing to do 
with report/test/fix.  We're immune to exploitation of bugs of this class 
regardless of whether they're known, regardless of whether any POC has 
been tested, and regardless of whether they've been fixed.

-Brad

Attachment: signature.asc
Description: Digital signature

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