* '''Launchpad entry''': none yet * '''Created''': <> by JohnMoser * '''Contributors''': JohnMoser * '''Packages affected''': == Summary == This spec defines an auditing aspect of the Ubuntu Hardened Team specified in HardenedUbuntu. == Rationale == The Ubuntu Hardened Team is made up of multiple sub-teams all approaching security from a different angle using a different set of tasks. One such important team is needed to audit for regressions in security features and for generally unfavorable conditions such as executable stacks. == Use cases == * doko uploads `gcc` 4.1.2; it is discovered that GccSsp is not properly enabled. `gcc` must be re-packaged and several packages must be rebuilt. * `gaim` has an executable stack. It is discovered that this is due to `libgcrypt11` not having properly marked assembly objects. It is determined that an executable stack is not necessary for `libgcrypt11` and so this is fixed. * `/usr/lib/libSDL-1.2.so.0.7.3` has a TEXTREL; this takes some examination and coding to remove, patches are sent upstream. == Scope == The scope for the Ubuntu Hardened Audit Team would follow the security features of Ubuntu Linux. Note that some of the features in this spec, such as PositionIndependentExecutables, are not yet in Ubuntu. We still describe how to handle them for informational purposes. The Ubuntu Hardened Audit Team will responsibilities including the following: * Audit for regressions in deployed security enhancements, such as: * GccSsp, in case binaries aren't getting protected * PositionIndependentExecutables, in case binaries aren't being made PIEs * Keep an up-to-date list with explanations of any situations where protections aren't applied. * Some binaries fail to compile as PIEs; this requires code changes. * Bugs in GccSsp may cause stack smash protection to trigger randomly. * Audit for binaries with unfavorable security attributes and fix them. * PT_GNU_STACK, which makes any binary using the library have an executable stack. * TEXTRELs; these have a two-fold effect. * ELF `.text` relocations take longer to perform than regular relocations, slowing down program load. * On systems with PaX `mprotect()` or with SELinux `execmod`, any form of TEXTREL detection (a compatibility feature) can be fooled. An attacker could use a return-to-libc style attack to return to `mmap()`; `mmap()` a library with a TEXTREL; and then perform the `mprotect()` sequence for the TEXTREL but return-to-`memcpy()` to write his shellcode instead of performing the relocation. The final return-to-lib will execute his injected shellcode. * Attempt to get binaries to build PIE where they don't already. == Design == Somebody should probably write a bunch of documentation as they go along. Besides that, get a team together to do the above as below. == Implementation == The implementation is mostly flexible. Details on some things that could need to be done eventually are here. '''Regressions''': * GccSsp regressions * Difficult to test for directly; however a build system tool can be written that automatically checks if the appropriate symbols are being exported from each object (`.o`) file needing it. * A regression test for GccSsp functionality is easy to write; just trigger a buffer overflow in a test function. * PositionIndependentExecutables * Programs will either fail to compile PIE, or will build as PIE and work. PIE requires a single register free; typically inline assembly (i.e. in the middle of C functions) breaks this. * MemoryProtection regressions * Any memory protections such as PaX `mprotect()` restrictions or SELinux `execmem`, `execstack`, `execheap`, and `execmod` permissions will occasionally break things. We expect Mono, Java, and qemu to break by nature; however other applications such as Rhythmbox or Totem may break if for example they request an executable stack and are denied. * MemoryProtection regressions need to be tracked so we know what packages do not have protection. * It is extremely favorable that we fix the root cause of the regression wherever possible. '''Reporting''': * Any non-pie binaries need to be listed. * Failed GccSsp needs to be listed as well. Also list the reason, which may be: * Bugs in GccSsp causing stack smash protection to trigger randomly. * Bugs in the program itself that trigger GccSsp by overflowing a buffer just barely into the canary. * '''These are extremely likely to represent a security hole'''. * Binaries that need adjusted MemoryProtections must be listed. '''Clean-Up''': * Executable stacks, TEXTRELS, and other bad things can be found with `scanelf` from `pax-utils`. Guide available at [[http://www.gentoo.org/proj/en/hardened/pax-utils.xml]]. * PT_GNU_STACK markings make any binary using the library have an executable stack. This causes these binaries to fail to load under PaX or SELinux strict memory protection policies without a modified `glibc`. * These can be removed by various techniques, such as those described at [[http://www.gentoo.org/proj/en/hardened/gnu-stack.xml]]. * `gcc` will generate code that executes on the stack if trampolines/nested functions are used. Rewriting code to not use trampolines will automatically eliminate the PT_GNU_STACK marking. * Sometimes hand-written assembly requires a PT_GNU_STACK. There are a few solutions here: * Build the library ''without'' the assembly code. * Rewrite the assembly code to not execute the stack ''and'' add the appropriate `.note.GNU-stack` section. * It is, obviously, perfectly acceptable to disable hand-written assembly code for shipped binaries pending a rewrite of the assembly code to correct the executable stack. * TEXTRELs require rewriting code to correct. * Binaries that refuse to build PIE require inline assembly to be rewritten or replaced with C code. * Typically avoiding the use of %ebx in inline assembly will work for i386. * You can pass C variables via asm constraints, i.e. `int __asm_a; __asm__ { MOV __asm_a,0 }`; `gcc` will automatically handle register allocation and the code will work. === Code === === Data preservation and migration === == Unresolved issues == == BoF agenda and discussion == ---- CategorySpec