PaXvExecShield

Differences between revisions 1 and 2
Revision 1 as of 2005-05-12 15:46:22
Size: 3094
Editor: pcp0012067827pcs
Comment: creat()
Revision 2 as of 2006-05-18 13:55:30
Size: 3089
Editor: c-68-33-112-13
Comment:
Deletions are marked like this. Additions are marked like this.
Line 45: Line 45:
   * Fairly Accurate    * Approximation
Line 47: Line 47:
   * All memory below the highest executable area of memory is implicitly executable; thus, some data that should be non-executable will be executable    * Highest PROT_EXEC address is last executable address; above this is non-executable data. Usually this means only the stack is non-executable.

This is just a simple low-down comparing PaX to Exec Shield so I don't have to clutter every other page horribly.

PaX

  • Fully cross-platform between many architectures including x86, amd64, PARISC, ppc, ppc64, sparc, sparc64...
  • PROT_EXEC enforcement
    • NX Emulation on x86
      • 100% Accurate
      • SEGMEXEC splits address space in half, ~0.7% performance overhead
      • PAGEEXEC uses CS limit tracking (like Exec Shield does), falling back to kernel-assisted MMU walking where that fails to provide perfect accuracy
    • Uses NX bit on other archs
      • 100% Accurate
      • No performance overhead
  • Address Space Layout Randomization
    • Low on 32-bit
      • Heap: 14 bit
      • Heap (PIE): 24 bit
      • Stack: 24 bit (256 megs)
      • mmap: 24 bit
    • High on 64-bit
      • Heap: 14 bit
      • Heap(PIE): 32 bit
      • Stack: 32 bit (64 gig)
      • mmap: 25 bit
  • Security policy
    • Defined by the administrator
      • Can be defined by paxctl/PT_PAX_FLAGS (which can nuke PT_GNU_STACK if there's no PT_PAX_FLAGS)
        • Per-binary policy
      • Can be defined by MAC (SELinux, RSBAC, GrSecurity)

        • Flexibility comes with the system used
    • Enforced by the kernel
      • Kernel enforces ASLR
      • Kernel enforces strict separation between write and execute
        • W|X memory cannot be requested via anonymous or file-backed mmap()
        • Shared memory segments can't be executable
        • Non-executable memory cannot become executable
        • Memory cannot become W|X
        • Files may still be mmap()ed in PROT_WRITE or PROT_EXEC; thus, they may be mapped PROT_WRITE, written, then mapped elsewhere (or unmapped and remapped) PROT_EXEC. ASLR helps prevent this situation from occurring during an attack

Exec Shield

  • Mainly x86 support, weak or accidental if any support elsewhere
  • PROT_EXEC enforcement
    • NX Emulation on x86
      • Approximation
      • Uses CS limit tracking
      • Highest PROT_EXEC address is last executable address; above this is non-executable data. Usually this means only the stack is non-executable.
      • Minimal performance overhead
    • Uses NX bit on other archs
      • 100% Accurate
      • No performance overhead
  • Address Space Layout Randomization
    • Lower than PaX
    • Need numbers, although kernel port of ES ASLR has something like 64K (12 bits) of stack randomization, later to become 2M (17 bits) on x86. Stack stuffing attacks can make brute forcing this randomization easy, even with brute force deterrance.
  • Security policy
    • Defined by the program
      • Program has complete control over its memory protections and does not need to follow any specific security policy
      • Administrator can weaken the security policy per-binary from what the program wants, but not strengthen it
        • Can disable Exec Shield
        • Can set PT_GNU_STACK to give an executable stack/heap to the program
    • Enforced by the program
      • Program has complete control over its memory protections and does not need to follow any specific security policy
    • ASLR is enforced by the kernel of course

PaXvExecShield (last edited 2008-08-06 16:21:01 by localhost)