ExecutableStacks

Differences between revisions 27 and 28
⇤ ← Revision 27 as of 2009-08-06 10:04:28 →
Size: 2619
Editor: 89
Comment:
← Revision 28 as of 2009-08-06 11:37:32 → ⇥
Size: 3309
Editor: sites
Comment:
Deletions are marked like this. Additions are marked like this.
Line 2: Line 2:

When the linker (ld) performs linking, it marks the stack as executable based on lowest common demoninator. For example, everything is marked non-executable except one .o file, so the entire library gets an executable stack. In the case of a shared library, this would pollute any program it was loaded into. (On i386, the assembler assumes that unmarked .S files need an executable stack, and marks it as such.)

If a user is running a PAE kernel or has other NX-memory protections, they lose the ability to protect that program's stack memory from execution, leaving it open to potential unknown future vulnerabilities that might try to execute shellcode from stack memory.
Line 4: Line 9:
   * check a .o file: "scanelf -e $BIN | grep X".    * check a .o file: "scanelf -e $BIN" shows an "X".

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).

When the linker (ld) performs linking, it marks the stack as executable based on lowest common demoninator. For example, everything is marked non-executable except one .o file, so the entire library gets an executable stack. In the case of a shared library, this would pollute any program it was loaded into. (On i386, the assembler assumes that unmarked .S files need an executable stack, and marks it as such.)

If a user is running a PAE kernel or has other NX-memory protections, they lose the ability to protect that program's stack memory from execution, leaving it open to potential unknown future vulnerabilities that might try to execute shellcode from stack memory.

  • Detection:

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

  • 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

  • zip (umarked asm)

  • bogl (nested function)

  • mono (unmarked asm)

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

No Stack Section

  • memtest86+ (is a boot-loaded ELF, not a big deal)

Fedora Patches for universe packages

SecurityTeam/Roadmap/ExecutableStacks (last edited 2017-08-22 14:25:31 by jdstrand)