User: Password:
Subscribe / Log in / New account

Stack Protection available for Fedora and RHEL 3 update 3

Stack Protection available for Fedora and RHEL 3 update 3

Posted Oct 14, 2004 18:46 UTC (Thu) by scripter (subscriber, #2654)
Parent article: Security-improving technologies which could be deployed now

The article claims that "Most popular Linux distributions do not make use of available security technologies that would deflect a large number of these attacks."

However, I'd like to point out that Fedora Core 1 and 2, as well as RHEL 3 update 3 provide ExecShield. ExecSheild, as I understand it, also provides Address Space Layout Randomization (ASLR) -- so PaX isn't the only show in town.

(Log in to post comments)

Stack Protection available for Fedora and RHEL 3 update 3

Posted Oct 21, 2004 12:12 UTC (Thu) by spender (subscriber, #23067) [Link]

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.

Stack Protection available for Fedora and RHEL 3 update 3

Posted Oct 21, 2004 19:38 UTC (Thu) by bluefoxicy (guest, #25366) [Link]

Redhat is smalltown. They're one distributor. You can get PaX, PIE, and SSP on Gentoo too, thanks to the efforts of the Hardened Gentoo team; that's still only one distribution. You can get these on Adamantix and a couple other security distros, but they're not being run all over the place and thus aren't "Popular Linux Distributions."

People use six major distributions, as I understand it:

- Debian
- Gentoo
- Mandrake
- Redhat/Fedora
- Slackware
- SuSE

Redhat supplies some protections in Fedora and RHEL. ES is like an immature PaX as far as I understand; PaX is 3 years older and has a much higher level of administrative control, allowing you to even go as far as allowing trampolines to execute from the stack, or to prohibit a program from doing unsafe mprotect() calls. I can't comment on their PIE stuff; and have I heard anything about SSP + RH at all, so I'd be interested to know what they have going there.

Gentoo supplies none of this by default; however, they do support all this, as the Hardened Gentoo project is an official subproject of Gentoo Linux. This doesn't get these into mainstream use on more than a fraction of users' boxes.

Other distributions like Adamantix go above and beyond the call of duty and supply this, that, and the other thing; I believe Adamantix goes as far as using RSBAC for a MAC system, which is not something you sit down and learn on the fly, or brush through in 2 hours. These systems are great for enterprise use; but besides not being widespread in general Linux use, they're a bit excessive to just throw on your gaming or web surfing box.

So that leaves us with Debian, Mandrake, SuSE, Slackware, and yes even most Gentoo installations. Also, Debian derivatives will be easily affected by Debian, which means getting these in Debian at least will also affect Ubuntu, Knoppix, Morphix (and thus Gnoppix), and most other Debian derivatives. I believe these all count as "Most popular linux distributions."

Stack Protection available for Fedora and RHEL 3 update 3

Posted Oct 21, 2004 21:02 UTC (Thu) by bluefoxicy (guest, #25366) [Link]

"and have I heard anything about SSP + RH at all"

--> and I haven't heard anything about SSP + RH at all

Sorry, I don't know wtf I was thinking when I typed and read that back, it made sense at the time.

Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds