On Thu, 18 Dec 2014 18:31:57 -0500 Daniel Micay <[email protected]> wrote: > Arch's single biggest security weakness is that it's not benefiting > from address space layout randomization (ASLR). Fixing this issue > would be a major step towards being a leader in this area. Many > distributions enable ASLR, stack protector, etc. for a chosen set of > "security critical" stuff but very few enable them across the board. > > Executable permissions on memory (NX bit) prevent an attacker from > directly injecting code via memory corruption vulnerabilities. It's > only truly useful in combination with ASLR because if the existing > code is in a known location it can be reused by the attacker.[1] > > [1] https://en.wikipedia.org/wiki/Return-oriented_programming > > The cost of ASLR is that it requires position independent > (relocatable) code (PIC), as is already required for all code in > dynamic libraries. > > On i686, PIC has a significant cost (up to 30% or more). The vanilla > kernel also lacks emulation of the NX bit and has no brute force > protection to make up for the smaller 32-bit address space. Only the > subset of users using grsecurity / PaX would truly benefit. I don't > care about i686 anyway. > > On x86_64, there's hardware support for position independent code so > it's essentially free. It does currently cost ~1% due to linker and > compiler limitations (indirection to access globals) but this has > been fixed in the binutils/gcc master branches. It's much cheaper > than the -fstack-protector-strong switch which we're already using, > and the security value is higher. > > The only real barrier to enabling it is the lack of support in GCC for > simply flipping it on by default. Library code is already built with > -fPIC and is then linked with -shared. Full ASLR requires building > the executable code with -fPIE (or -fPIC, which isn't as cheap) and > then linking with -pie. There are two approaches to this: > > 1) Patching the toolchain's spec files (Hardened Gentoo) > 2) Wrapper scripts for clang/gcc/ld.bfd/ld.gold (Debian, Fedora, > Ubuntu) > > Upstream hasn't accepted various forms of the first option, so I > don't think it's a suitable approach for us. The hardening-wrapper > package implements the second option and also enforces our existing > hardening flags for build systems ignoring CFLAGS/CXXFLAGS/LDFLAGS. > > All it would take is either adding hardening-wrapper to the default > devtools packages list or making it part of base-devel. > > Here's an example with a small C program: > > strcat@thinktank i ~ master % cat test.c > #include <stdio.h> > > static void foo() {} > static int bar = 5; > > int main(void) { > int baz = 5; > printf("function: %p, data: %p, stack: %p\n", foo, &bar, &baz); > return 0; > } > > Without the hardening-wrapper package installed: > > strcat@thinktank i ~ master % gcc test.c -o test > strcat@thinktank i ~ master % checksec --file test > RELRO STACK CANARY NX PIE > RPATH RUNPATH FILE No RELRO No canary found NX > enabled No PIE No RPATH No RUNPATH test > strcat@thinktank i ~ master % ./test function: 0x400506, data: > 0x600980, stack: 0x7fff12ba3a7c strcat@thinktank i ~ master % ./test > function: 0x400506, data: 0x600980, stack: 0x7fffa47958fc > > With the hardening-wrapper package installed: > > strcat@thinktank i ~ master % gcc test.c -o test > strcat@thinktank i ~ master % checksec --file test > RELRO STACK CANARY NX PIE > RPATH RUNPATH FILE Partial RELRO Canary found NX > enabled PIE enabled No RPATH No RUNPATH test > strcat@thinktank i ~ master % ./test function: 0x7f267e569800, data: > 0x7f267e76a050, stack: 0x7fff3ee5ea14 strcat@thinktank i ~ master > % ./test function: 0x7f6a06b3e790, data: 0x7f6a06d3f048, stack: > 0x7fff76a891bc > > The defaults in /etc/hardening-wrapper.conf can be overridden via env > variables: > > strcat@thinktank i ~ master % HARDENING_STACK_PROTECTOR=0 gcc test.c > -o test strcat@thinktank i ~ master % checksec --file test > RELRO STACK CANARY NX PIE > RPATH RUNPATH FILE Partial RELRO No canary found NX > enabled PIE enabled No RPATH No RUNPATH test > > The need to use wrapper scripts is a bit ugly, but I think it's a > nicer approach than tracking down and patching dozens of build > systems to respect CFLAGS/LDFLAGS and it's the only realistic way to > enable PIE. The only alternative short of patching GCC spec files is > manually specifying the flags in thousands of executable-only > packages, and patching any build system producing both binaries and > libraries (yikes!). >
I already use hardening-wrapper for nginx and I'd like to see it enabled by default for all our packages, so +1 from me. B
pgpCGYsaeOaTH.pgp
Description: OpenPGP digital signature
