|Main Archive Page > Month Archives > full-disclosure-uk archives|
Few of you may have seen my comments on the following article in RedHat magazine:
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:
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 <firstname.lastname@example.org> 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.