Hello,
Please don't forget to CC me, as I'm not yet subscribed to the list.
(will rectify it soon, once I improve my mail filter)

As it has come to my attention, Sabayon doesn't build its software
with either PIE or stack protector.
This is quite suprising, as even major distributions like Fedora or
Ubuntu enable at least partial SSP.

In Gentoo, this is essentially trivial, by just enabling USE=hardened
and rebuilding gcc. This will add CFLAGS="-fstack-protector-all -fPIE
-D_FORTIFY_SOURCE=2" and LDFLAGS="-Wl,-z,now"
to everything the default compiler builds. This can be temporarily
disabled using eselect gcc and picking one of the options, or
filtering flags in an ebuild.

Additional assembly-bearing packages such as mplayer can have it also
hardened (for PIE) with USE=pic, but this might come at an important
performance cost.
My own tests with Mesa shown a 25% performance drop in gallium from
USE=pic. This is probably not worth it for a desktop distribution and
affects only a score of packages.

On x86-64, Position Independent Executables (PIE) comes with no
performance cost, while on x86 it costs as much as
-fno-omit-frame-pointer. (below 10%)
This feature has to be combined with Address Space Layer Randomization (ASLR).
Linux kernel since 2.6.25 contains Exec Shield, which is such an
implementation. Not as strong as grsecurity PaX, but still quite
decent and making life far harder for hackers.

PIE protects against local exploits, but using it completely
effectively requires an additional tiny kernel tuneup, such as
disabling /proc/self/maps (trivial patch, also part of grsecurity)
or preventing access to it with an ACL, such as Tomoyo, SELinux (both
mainline) or grsecurity (patch).
Once you have that done, the only remaining attack is trying to damage
the random number generator, which is hard on Linux.

Stack Protector is another tool almost completely (see above caveat)
preventing attacks against automatically allocated variables.
This means that even if code allows an overflow, the compiler will
check the access after the write. Improves strength against a class of
both local and remote exploits.
Stack Protector support can also be enabled for kernel code with a
kernel config flag. (since 2.6.32 I think)

Of course, this is not end-all-be-all. Both of these techniques
necessitate good logging of crashes to avoid brute forcing.
To that end, kernel auditing subsystem can be used (with auditd) or
grsecurity patchset - and a bunch of simple scripts to kill any
session that's misbehaving and e.g. stop cron from restarting
services.
Tools such as Nagios can provide constant monitoring. None of it
matters for services that don't automatically restart, but stopping
the local sessions that crash can well still be useful against
bruteforcing local exploits.

Bottom line: it's not foolproof, but it's cheap and quite effective regardless.

USE=hardened also enables 2 linker flags:
-Wl,-z,relro - makes text relocations (if any) read only - this is
default in binutils since at least 2.20
and
-Wl,-z,now - forces all dynamic libraries to be linked in at the start
of the executable, which prevents .so switching attacks on long
running daemons.
This might cost some in memory and load time for applications with
lots of .so linked in, but is usually unnoticeable.

Another enabled CFLAGS is a special glibc flag, -D_FORTIFY_SOURCE=2.
This feature will cause simple memory errors and bad practices to be
caught at build time, as well as enable checked malloc.
Cost of the feature is very low as opposed to hard randomization like
in libmudflap.
Quite a few distributions use it to catch bad code in many packages.
Gentoo contains some fix patches that haven't yet been sent upstream
as well.

Here's some general writeup:
https://wiki.ubuntu.com/ToolChain/CompilerFlags
Note: while Ubuntu applies SSP to smaller stack variables than
default, they don't enable it for all. Not sure why.

Another writeup by flameeyes goes here: (with a minor mistake about
ASLR availability)
http://blog.flameeyes.eu/2009/11/02/the-pie-is-not-exactly-a-lie

-- 
Radosław Szkodziński


Reply via email to