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

[Steve Grubb <sgrubb () redhat com>]

Hi Brad,

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

On Saturday 03 March 2007 11:16, Brad Spengler wrote:
> 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.

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.

But I looked at the grSec kernel and found this in grsecurity/grsec_init.c:

int grsec_enable_shm;
int grsec_enable_link;
int grsec_enable_dmesg;
int grsec_enable_fifo;
int grsec_enable_execve;
int grsec_enable_execlog;
int grsec_enable_signal;
int grsec_enable_forkfail;
int grsec_enable_time;
int grsec_enable_audit_textrel;
int grsec_enable_group;
int grsec_audit_gid;
int grsec_enable_chdir;
int grsec_enable_audit_ipc;
int grsec_enable_mount;
<snip>

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?


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

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

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

No, you can easily confine an app in a few minutes. What they need to do is to 
review what the application is asking permission for. If its trying to get 
write access to shadow, they might want to seriously consider whether the app 
really needs that. 

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.

> What if no source is available?

You don't need the source to write policy.

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

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

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

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