Ubuntu Wiki

• Launchpad entry: none yet

• Created: 2006-08-01 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