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@xxxxxxxxxxxxxxxx>
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
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/