Scribd Logo
Upload

Welcome to Scribd!

  • 39 views

    Defense Against Control Hijacking - Platform Defenses

    Uploaded by

    Harpreet Singh
    This document discusses platform defenses against control hijacking attacks. It describes fixing bugs, marking memory as non-executable to prevent code execution (DEP), and adding runtime code to detect buffer overflows. It also discusses return-oriented programming (ROP) attacks and defending against them using address space layout randomization (ASLR) to randomize the locations of libraries and other memory areas.

    Copyright:

    © All Rights Reserved
    Download as PPTX, PDF, TXT or read online from Scribd

    Defense Against Control Hijacking - Platform Defenses

    Uploaded by

    Harpreet Singh
    39 views8 pages
    This document discusses platform defenses against control hijacking attacks. It describes fixing bugs, marking memory as non-executable to prevent code execution (DEP), and adding runtime code to detect buffer overflows. It also discusses return-oriented programming (ROP) attacks and defending against them using address space layout randomization (ASLR) to randomize the locations of libraries and other memory areas.

    Original Title

    Module-1.4.pptx

    Copyright

    © © All Rights Reserved

    Available Formats

    PPTX, PDF, TXT or read online from Scribd

    Did you find this document useful?

    Is this content inappropriate?

    This document discusses platform defenses against control hijacking attacks. It describes fixing bugs, marking memory as non-executable to prevent code execution (DEP), and adding runtime code to detect buffer overflows. It also discusses return-oriented programming (ROP) attacks and defending against them using address space layout randomization (ASLR) to randomize the locations of libraries and other memory areas.

    Copyright:

    © All Rights Reserved
    Download as PPTX, PDF, TXT or read online from Scribd
    Download as pptx, pdf, or txt
    39 views8 pages

    Defense Against Control Hijacking - Platform Defenses

    Uploaded by

    Harpreet Singh
    This document discusses platform defenses against control hijacking attacks. It describes fixing bugs, marking memory as non-executable to prevent code execution (DEP), and adding runtime code to detect buffer overflows. It also discusses return-oriented programming (ROP) attacks and defending against them using address space layout randomization (ASLR) to randomize the locations of libraries and other memory areas.

    Copyright:

    © All Rights Reserved
    Download as PPTX, PDF, TXT or read online from Scribd
    Download as pptx, pdf, or txt
    of 8

    Module 1.

    4
    Defense Against Control Hijacking
    Platform Defenses
    Control Hijacking

    Platform Defenses
    Preventing hijacking attacks
    1. Fix bugs:
    Audit software
    Automated tools: Coverity, Prefast/Prefix.
    Rewrite software in a type safe languange (Java, ML)
    Difficult for existing (legacy) code

    2. Concede overflow, but prevent code execution

    3. Add runtime code to detect overflows exploits


    Halt process when overflow exploit detected
    StackGuard, LibSafe,
    Marking memory as non-execute (W^X)

    Prevent attack code execution by marking stack and heap as non-


    executable DEP Data Execution Prevention
    NX-bit on AMD Athlon 64, XD-bit on Intel P4 Prescott
    NX bit in every Page Table Entry (PTE)
    Deployment:
    Linux (via PaX project); OpenBSD
    Windows: since XP SP2 (DEP)
    Visual Studio: /NXCompat[:NO]
    Limitations:
    Some apps need executable heap (e.g. JITs).
    Does not defend against `Return Oriented Programming exploits
    Examples: DEP controls in Windows

    DEP terminating a program


    Attack: Return Oriented Programming
    (ROP)
    Control hijacking without executing code
    stack libc.so
    args
    retaddr exec()
    sfp printf()

    localbuf /bin/sh
    Response: randomization
    ASLR: (Address Space Layout Randomization)
    Map shared libraries to rand location in process
    memory
    Attacker cannot jump directly to exec function
    Deployment: (/DynamicBase)
    Windows 7: 8 bits of randomness for DLLs
    aligned to 64K page in a 16MB region 256 choices
    Windows 8: 24 bits of randomness on 64-bit processors
    Other randomization methods:
    Sys-call randomization: randomize sys-call ids
    Instruction Set Randomization (ISR)
    ASLR Example
    Booting twice loads libraries into different locations:

    e: everything in process memory must be randomized


    stack, heap, shared libs, base image
    Win 8 Force ASLR: ensures all loaded modules use ASLR

    You might also like