ExecutableStacks

Revision 24 as of 2009-08-06 09:20:07

Clear message

There are still some programs that have executable stack regions, which results in their being vulnerable to exploitation via stack memory. There are only a few very rare situations where executable stacks are actually desired, the rest are usually the result of lacking flags in assembly code or using nested functions (which are generally avoidable).

  • Detection:

    • check an ELF binary: "readelf -lW $BIN | grep GNU_STACK" shows with "E" flag.
    • check a .o file: "scanelf -qe $BIN" shows with "X" flag.

  • Information: Gentoo write-up about exec stack handling: http://www.gentoo.org/proj/en/hardened/gnu-stack.xml

  • Potential Solutions:

    • fix assembly source by adding flags to assembler: .section        .note.GNU-stack, "", @progbits

    • fix compiler's default when encountering unmarked assembly: -Wl,-z,noexecstack will change the behavior of compiler's asm-without-stack-markings defaults.

    • rework code to avoid using nested functions.
    • force markings into a safe state via "execstack -c $BINARY" during package build.

Main/Restricted Packages

Originally generated from the ELF files with executable stacks in Karmic main.

Fixed

Nested Functions

Uses Nested Functions which compiler generates as trampolines on the stack.

Trampolines

  • klibc (setjmp implementation)
  • kexec-tools (statically linked against klibc)

Shipped Precompiled Binary

  • fglrx-installer

  • nvidia

    • nvidia-graphics-drivers-173
    • nvidia-graphics-drivers-180
    • nvidia-graphics-drivers-71
    • nvidia-graphics-drivers-96

Unmarked Assembler

Unclassified

  • icon
  • john
  • link-grammar
  • mbr
  • memtest86+

Fedora Patches