Message-Id: <200705141618.01626.sgrubb@redhat.com>
Date: Mon, 14 May 2007 16:18:01 -0400
From: Steve Grubb <sgrubb@...hat.com>
To: dailydave@...ts.immunitysec.com
Cc: full-disclosure@...ts.grok.org.uk, Brad Spengler <spender@...ecurity.net>
Subject: Re: [Dailydave] What RedHat doesn't want you to
	know about ExecShield (without NX)

On Monday 14 May 2007 10:13, Brad Spengler wrote:
> Take note of their misleading (another word for completely inaccurate)
> diagrams, inability to understand what exactly the new additions to SELinux
> have to do with "buffer overflows," 

SE Linux has nothing to do with buffer overflows besides checking that the 
memory permissions are sane. The buffer overflow detection is a combination 
of gcc and glibc.

> Then there's the design issue RedHat doesn't want you to know about:
> under ExecShield with no NX, every writable mapping lower than the
> highest executable mapping in the address space is executable.

The address space is split into two parts: the lower part which is executable, 
the higher part which is not.  The kernel code dynamically adjust the 
boundary between the two depending in where DSOs are loaded and PROT_EXEC 
mappings in general happen.  The highest executable mapping decides the 
boundary.

This all works well if all DSOs and PROT_EXEC mappings happen below the 
executable itself and this is what the ASCII-safe mapping does, as a side 
effect.  prelink has the option --exec-shield to lay out DSOs at those low 
addresses.

I cannot remember anybody ever claiming that this protection is as effective 
as NX.  It isn't, it never will be.  But for many/most programs we ship it is 
and we could (with some work) show that this is the case at least for the 
most important programs (network visible, etc).

You can read about it in

   http://people.redhat.com/drepper/nonselsec.pdf

section 4, "Implementation Details".  That weakness is documented there, so I 
don't know why you think we don't want people to know.


> For PIE binaries, due to their weaker form of PaX's ASLR, this becomes
> even more interesting since it produces what I call "nondeterministic
> security."  Since PIE binaries are treated just like libraries, they
> may or may not be loaded as the highest-mapped library in the system.
> Since there is only one PIE binary loaded and many more libraries being
> loaded, this means that there's a large chance that the bss/data on the
> main executable will be unprotected -- writable and executable.

This still only refers to no-NX.

The mapping addresses are a policy of the kernel.  The implementation AFAIK 
always tried to use low addresses for executable mappings.  I really don't 
see why any of this is supposed to be different from the general DSO-loading 
task and problem.  If the kernel loads DSOs and PIEs up high, a large portion 
of the address space is exposed.  Sure.  But if not, the portion is small.  
And the kernel policy is to do the latter.

And all this is completely irrelevant with NX hardware.

> On another note, the following bug fixed in v2.6.21 of the Linux kernel:
> commit fdc30b3d448bf86dd45f9df3e8ac0d36a3bdd9b2
> Author: Taku Izumi <izumi2005@...t.fujitsu.com>
> Date:   Mon Apr 23 14:41:00 2007 -0700
>
>     Fix possible NULL pointer access in 8250 serial driver

Yes, NULL is a more common invalid address in references.  But it's certainly 
not the only one.  Until the kernel address space has no execution permission 
for any of the userlevel data any stray pointer use will be a problem.  
Userlevel can map pages at all addresses the kernel incorrectly refers to.  
Randomizing the address of the kernel itself can help a bit but doesn't solve 
the issue.  Nor does disallowing to map at address zero.

> is 100% exploitable as a root user (thanks to solar designer,
> /proc/tty/driver has had its permissions restricted that would have
> prevented this from being exploitable by a non-root user).

If you are root, there are easier ways to take over the machine. :)

> It's easy to misinform your users when no one questions your
> information.  It's harder when the entire security community knows about
> it.  I had hoped my previous exploit would have kept RedHat from getting
> away with publishing an article containing the diagram it has, but it
> appears to have not been effective. 

Brad, I have a feeling this will always be true. No matter how much you rant, 
someone will draw a diagram that you won't like. :))

But I do appreciate your critique.

-Steve

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists