Hi,
I just read this interesting article on lwn: http://lwn.net/Articles/106214/ (lwn subscriber only)
This talks about things like: 1 Stack Smash Protection 2 PAX (alternative Exec Shield) 3 Position Independent Executables.
Stack Smash Protection sounds like a cool feature to me. I don't know what the performance impact is, but as a developer even if it is to slow to use by default I would love to have it intergrated into the gcc shipped by Fedora to make debugging easier.
PAX uses tricks to get a non executable stack, and assignes random addresses to PIE executables, which Fedora already has in the form of Exec Shield, good! But if I undertand it correctly PAX does more for example also make data pages non executable, this might be something worth looking into.
PIE we already have, good!
Regards,
Hans
Stack Smash Protection sounds like a cool feature to me. I don't know what the performance impact is, but as a developer even if it is to slow to use by default I would love to have it intergrated into the gcc shipped by Fedora to make debugging easier.
I use a specially doctored version of gcc with propolice compiled in. I have helped code review & submit corrections to propolice. I can say that its pretty good, but not bulletproof. Its worth adding for the fact that it is one more layer should there be holes in the other protection mechanisms. Performance is pretty good. 5-10% performance hit. However, there is one small issue. It needs to read from /dev/random and write to /dev/syslog. This is not in all policies and has to be manually added. I see the avc messages all the time.
I also use libsafe which seems to catch more stack smashing attempts than propolice. I have corrected a number of bugs in it and shared them with the developers. I also extended libsafe to cover more vectors of attack. You can find the updated copy here: www.web-insights.net/libsafe. There is a perfomance hit, but its small. I'd rather a 2 Ghz machine with cycles to burn run with libsafe + propolice than spend 2 days setting up the machine after its hacked. libsafe does use an LDPRELOAD variable to intercept calls. This means that it offers no protection to setuid/setgid programs. selinux may also object to it.
But if I undertand it correctly PAX does more for example also make data pages non executable, this might be something worth looking into.
Some of the things it does makes software debug impossible. valgrind sometimes has problems with it. I think there are some bits of it that are good, as well as the openwall linux patch set. It would be better if these were adopted into the kernel rather than maintained as a patch to it.
But something that neither of these address, is plain logic errors. Every week I find a pretty good problem that scanners (flawfinder/lint/valgrind), stack protectors (propolice/libsafe), and se linux cannot catch. Part of the solution has to be peer review.
-Steve Grubb
_______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com
On Thu, 2004-10-14 at 06:52, Hans de Goede wrote:
Stack Smash Protection sounds like a cool feature to me. I don't know what the performance impact is, but as a developer even if it is to slow to use by default I would love to have it intergrated into the gcc shipped by Fedora to make debugging easier.
you can use jakub's gcc 4 / glibc rpms and something like this too
PAX uses tricks to get a non executable stack, and assignes random addresses to PIE executables, which Fedora already has in the form of Exec Shield, good! But if I undertand it correctly PAX does more for example also make data pages non executable, this might be something worth looking into.
execshield makes data pages also non executable
Arjan van de Ven wrote:
On Thu, 2004-10-14 at 06:52, Hans de Goede wrote:
Stack Smash Protection sounds like a cool feature to me. I don't know what the performance impact is, but as a developer even if it is to slow to use by default I would love to have it intergrated into the gcc shipped by Fedora to make debugging easier.
you can use jakub's gcc 4 / glibc rpms and something like this too
You mean the default RPM's in FC3 or ... ? and how do I do this something like this?
Thanks,
Hans
On Thu, Oct 14, 2004 at 06:17:41PM +0200, Hans de Goede wrote:
Arjan van de Ven wrote:
On Thu, 2004-10-14 at 06:52, Hans de Goede wrote:
Stack Smash Protection sounds like a cool feature to me. I don't know what the performance impact is, but as a developer even if it is to slow to use by default I would love to have it intergrated into the gcc shipped by Fedora to make debugging easier.
you can use jakub's gcc 4 / glibc rpms and something like this too
You mean the default RPM's in FC3 or ... ? and how do I do this something like this?
You can compile with CC=gcc4 CFLAGS=-fmudflap LDFLAGS=-lmudflap to get instrumented binaries. You'll need to install the libmudflap packages to get that to work.
Tim. */
Hans de Goede <j.w.r.degoede <at> hhs.nl> writes:
Hi,
I just read this interesting article on lwn: http://lwn.net/Articles/106214/ (lwn subscriber only)
Yay :)
This talks about things like: 1 Stack Smash Protection 2 PAX (alternative Exec Shield) 3 Position Independent Executables.
Stack Smash Protection sounds like a cool feature to me. I don't know what the performance impact is, but as a developer even if it is to slow to use by default I would love to have it intergrated into the gcc shipped by Fedora to make debugging easier.
I use it.
The performance impact isn't noticable, but it's highly variable. It's theoretical maximum is something like 8%; and it drops when a function gets bigger, or when functions aren't protected.
You can use heuristics (-fstack-protector) to protect only functions with a local character array; or just protect all (-fstack-protector-all). With the heuristics, it's likely you don't much encounter protected functions.
My best guess looking at the design (not the code) is that it takes about 4 instructions to protect a function on the base, plus one more per passed argument, based on the below.
SSP rearranges variables at compile time. This produces no runtime overhead.
SSP protects a function with a local char[] using a __guard value. This would require expanding the stack frame. The best way is to allocate the entire stack frame at once, so I assume the GCC devs are smart and that this produces 0 extra instructions. Next, you need to check the GOT for __guard (I'm assuming O(1), so one instruction), and use MOV to copy __guard to local_guard (1 insn).
At return in a protected function, __guard must be checked with CMP. If it's fine, then JE past the code that calls __stack_smash_handler(). Two more instructions. This totals 4 for a __guard protection on a function.
To protect passed arguments, the stack frame has to be made bigger (no overhead?). A MOV based on an offset from an address in some register has to be made for each argument (1 insn for each argument).
I'm guessing at internals, but I think most of this is possible. I'm not sure about the O(1) GOT lookup. I'm probably wrong there.
PAX uses tricks to get a non executable stack, and assignes random addresses to PIE executables, which Fedora already has in the form of Exec Shield, good! But if I undertand it correctly PAX does more for example also make data pages non executable, this might be something worth looking into.
PaX makes a strict separation between Writable and Executable memory. It also has more accurate NX emulation on x86. Ingo has admitted that PaX is competetive with Exec Shield in recent LKML posts:
(but no doubt PaX is fine and protects against exploits at least as effectively as (and in some cases more effectively than) exec-shield, so you've definitely not made a bad choice.)
It's also older and still actively developed (older and inactive is bad, older and active is good, younger and active is not quite as good unless your developer is quite a lot more competant on the subject).
SEGMEXEC on x86 splits the address space in half to emulate an NX bit; I've never seen this cause a problem in anything. PAGEEXEC used to use kernel-assisted MMU walking, which can be very high overhead depending on memory access patterns; now it uses the same method Exec Shield uses, but falls back to kernel-assisted MMU walking if that fails (due to mprotect()ing a higher address with PROT_EXEC).
PIE we already have, good!
Feh, your PIE is a joke. My ENTIRE SYSTEM is PIE, save for what won't compile PIE. I don't use Fedora, but last I heard, only a few programs were PIE.
The overhead of PIC (based on nbyte-bench) is something like 0.99002% on x86, and 0.02% on amd64. There's another caveat: -fomit-frame-pointer usually gives a -5% overhead (i.e. it removes overhead and thus programs use less CPU). This is lost on x86; no effect (ok, 0.01%) on amd64.
That being said, you have to understand that libraries are ALL PIC. You lose NOTHING in libraries by going to PIE. All plug-ins to anything (except gimp?), all encoder and decoder libraries, libtheora, libogg, libvorbis, libvorbisenc, liblame, libmad, libzlib and libbzip2, ALL YOUR HEAVY LIFTING is done in libraries.
I haven't profiled it but I'm fairly sure that any large amounts of CPU are typically spent in PIC code anyway. I'm pretty certain that the real-world system-wide impact of PIE is dismally low due to the low amount of time the actual executable load module spends on the CPU versus the libraries it uses.
Regards,
Hans
Stack Smash Protection sounds like a cool feature to me. I don't know what the performance impact is, but as a developer even if it is to slow to use by default I would love to have it intergrated into the gcc shipped by Fedora to make debugging easier.
well.. gcc in fc4 (well rawhide right now) has something that has a quite similar effect, with basically zero performance impact. Try it ;)
PAX uses tricks to get a non executable stack, and assignes random addresses to PIE executables, which Fedora already has in the form of Exec Shield, good! But if I undertand it correctly PAX does more for example also make data pages non executable, this might be something worth looking into.
Exec-Shield makes datapages also non-executable. There is very little practical difference between PAX and Exec-Shield protection wise. There are theoretical differences, mostly comming from a different viewpoint (Exec-Shield is about being as secure as possible without breaking things, while PaX does make the deliberate choice to break things. The difference is small, the things that "break" are rare. very rare.) The reason Exec-Shield does this is because the worst thing that can happen is to be too secure, so secure that all sysadmins just turn it off entirely.
-
Arjan van de Ven -
Hans de Goede -
John Richard Moser -
Steve G -
Tim Waugh