0% found this document useful (0 votes)
43 views

Defense Against Control Hijacking - Platform Defenses

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.

Uploaded by

Harpreet Singh
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
43 views

Defense Against Control Hijacking - Platform Defenses

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.

Uploaded by

Harpreet Singh
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 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