[arch-dev-public] Proposal: enabling full ASLR on x86_64 via hardening-wrapper

[Bartłomiej Piotrowski]

On Thu, 18 Dec 2014 18:31:57 -0500
Daniel Micay <danielmicay at gmail.com> 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 at 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 at thinktank i ~ master % gcc test.c -o test
> strcat at 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 at thinktank i ~ master % ./test function: 0x400506, data:
> 0x600980, stack: 0x7fff12ba3a7c strcat at thinktank i ~ master % ./test
> function: 0x400506, data: 0x600980, stack: 0x7fffa47958fc
> 
> With the hardening-wrapper package installed:
> 
> strcat at thinktank i ~ master % gcc test.c -o test              
> strcat at 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 at thinktank i ~ master % ./test function: 0x7f267e569800, data:
> 0x7f267e76a050, stack: 0x7fff3ee5ea14 strcat at thinktank i ~ master
> % ./test function: 0x7f6a06b3e790, data: 0x7f6a06d3f048, stack:
> 0x7fff76a891bc
> 
> The defaults in /etc/hardening-wrapper.conf can be overridden via env
> variables:
> 
> strcat at thinktank i ~ master % HARDENING_STACK_PROTECTOR=0 gcc test.c
> -o test strcat at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/arch-dev-public/attachments/20141224/ef802e74/attachment.bin>