Date: Mon, 14 May 2007 10:13:19 -0400
From: spender@...ecurity.net (Brad Spengler)
To: dailydave@...ts.immunitysec.com
Cc: full-disclosure@...ts.grok.org.uk
Subject: What RedHat doesn't want you to know about
	ExecShield (without NX)

Few of you may have seen my comments on the following article in RedHat 
magazine:
http://www.redhatmagazine.com/2007/05/04/whats-new-in-selinux-for-red-hat-enterprise-linux-5/

I think the issue deserves more widespread attention among the security 
community, however, since RedHat seems to be involved in a concerted 
effort of disinformation for both SELinux and ExecShield.  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," and then note my several comments below, 
where I also comment upon some ExecShield behavior under a non-NX system.
I present you with links to several previous articles on RedHat 
security and the official ExecShield paper, all written by developers 
at RedHat, who make several inaccurate/misleading statements regarding 
the effectiveness under ExecShield in a non-NX environment (which 
RedHat would have you believe does not exist anymore).

I encourage you to read all the comments, however the basic idea is that 
ExecShield has had problems ever since it was introduced into Fedora and 
then into RHEL (sometimes due to improper marking with the flawed 
PT_GNU_STACK which under ExecShield with no NX makes the entire address 
space executable, other times with bugs in the ExecShield 
implementation that ended up leaving over half of the services on a 
Fedore Core 3 system being protected improperly).

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.

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.

Ingo knows about this (I mailed him privately about the problems I saw 
with Fedora Core 3, which resulted in an updated kernel -- though I 
don't believe users were really notified of the fact they were being 
fooled into thinking certain protection was being applied to their 
binaries that in fact was not), but it seems he's not talking to anyone 
else at RedHat if you look at the articles that keep coming out about 
their "security enhancements."  In my last comment I list articles I 
found about ExecShield with the inaccurate statements (I couldn't find 
any with an accurate discussion of them).  Among them:
http://www.noncombatant.org/trove/drepper-redhat-security-enhancements.pdf
http://www.redhat.com/magazine/009jul05/features/execshield/
http://www.redhat.com/f/pdf/rhel/WHP0006US_Execshield.pdf

I really hope I don't see another article from RedHat about SELinux 
containing diagrams like:
http://farm1.static.flickr.com/223/481929076_959cdef97d_o.jpg

or an article about ExecShield saying that its protection on a 
processor without NX is comparable to one with NX.

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

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).  Of course, 
this is just one more example of a bug not being recognized by kernel 
developers as being exploitable.  It's also one more vector to 
completely compromise a box running SELinux (using the handy 
disable_selinux() code released in my previous exploit)

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.  It's in everyone's best interests 
for RedHat to be more honest in their discussion of their security 
technologies, and I hope they will make a concerted effort towards that.

-Brad

Download attachment "signature.asc" of type "application/pgp-signature" (190 bytes)

_______________________________________________
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