Stack Protection available for Fedora and RHEL 3 update 3
Posted Oct 21, 2004 12:12 UTC (Thu) by spender
In reply to: Stack Protection available for Fedora and RHEL 3 update 3
Parent article: Security-improving technologies which could be deployed now
The comment is correct, because ExecShield doesn't stop the attacks. Take a look at your /proc/<pid>/maps listing and try to find randomization in the libraries mmaped in the "ascii armor" region. Also note that the ascii armor region doesn't even necessarily protect from ret2libcs with vulnerable strcpy functions, not to mention it does nothing for any other memory copying function that doesn't deal with strings.
Also note that PaX provides true per-page NX semantics, while Exec-shield does not. An "executable-stack" in Exec-shield means the entire address space is executable. And with the bugs in Fedora's userspace labeling certain libraries as needing executable stacks (such as libcrypto), any applications loading these libraries will not be protected at all. Funny that it's Fedora users running PaX that have found these bugs. Fedora users with exec-shield would have been unknowingly unprotected (a false sense of security).
Exec-shield had a bug before that left a page in the .bss writable and executable, which couldn't be discerned from the maps file. It was months until someone ran paxtest against an exec-shield machine and found the bug. Exec-shield still has vulnerabilities that make it useless against local attackers. For instance, Red Hat still has not fixed the LD_DEBUG information leaking problem in their glibc. mmap randomization for suid apps is useless with this information.
Security companies are developing exploits that still work reliably against Exec-shield. It was noted on the daily-dave list that Immunity has developed such an exploit. Blackhats are developing the same kinds of exploits. Red Hat is only hurting the lowest denominator of "hackers." Their implementations are so flawed (and the flaws are well known among the blackhat community) that they are useless against more skilled attackers. Red Hat is interested in buzzwords and publicity. They simply do not understand security. Check their bugzilla regarding LD_DEBUG. Even their main glibc guy (Jakub Jelinek) does not recognize the security implications, while more intelligent distros like Gentoo have already fixed the bug. Stupidity doesn't mix well with a bad case of NIH.
Also note that PaX is the only project handling the problem of exploitation of the kernel itself. PaX currently provides non-executable pages for the kernel on i386. It also causes constants and the syscall table to actually be read-only. By the way, I've spoken to a Microsoft security engineer who said that what PaX is doing for the kernel is impossible ;)
PaX also has recently updated its implementation of PAGEEXEC that has made the performance hit comparable to SEGMEXEC (for cpus other than P4) without the address space limitation.
to post comments)