ExecutableStacks

Differences between revisions 48 and 49
⇤ ← Revision 48 as of 2009-09-22 18:15:15 →
Size: 3904
Editor: 72-254-104-217
Comment:
← Revision 49 as of 2009-09-22 21:45:11 → ⇥
Size: 3947
Editor: 72-254-16-5
Comment:
Deletions are marked like this. Additions are marked like this.
Line 43: Line 43:
 * mountall (nested functions)  * [[https://bugs.launchpad.net/bugs/434813|mountall]] (nested functions)

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 the lowest common demoninator. For example, if everything is marked non-executable except one .o file, the entire library would get marked for an executable stack. In the case of a shared library, this would pollute any program it was loaded into. (The assembler assumes that unmarked .S files need an executable stack, and mark them accordingly.)

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:

    • found on the system, check an ELF binary: "readelf -lW $BIN | grep GNU_STACK" shows with "E" flag.
    • found in a build, 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:

      • GNU as: 

        .section        .note.GNU-stack, "", @progbits

      • YASM: 

        %ifidn __OUTPUT_FORMAT__,elf
section .note.GNU-stack noalloc noexec nowrite progbits
%endif

    • fix compiler's default when encountering unmarked assembly: -Wa,--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

In Progress

  • fglrx-installer (shipped precompiled binaries)

  • nvidia (shipped precompiled binaries)

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

  • mountall (nested functions)

Trampolines

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

  • mono (but only in the i386 debugger, it seems)

Nested Functions

Uses Nested Functions which compiler generates as trampolines on the stack. Not allowed by ISO C.

Unmarked Assembler

  • None known

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)