buffer_overflow_mitigation

Mitigation againstBuffer Overflow Attacks
1
A buffer on the stack has an un-checked bound.A malicious input could modify program control flow by overwriting data on the stack, e.g. saved EIP.Malicious code can be injected on the stack and EIP can be made to point to it.Key to a successful stack overflow attackThe modified control gets loaded into EIPe.g. the vulnerable function successfully“returns;”Must be able to predict the address of the injected codeThe injected code must be executable
Stack Overflow Review
2
Mitigation1: stack address randomization
The OS randomly picks a location for the program stack.The chance the attacker can guess the correct stack location is slim.Where shall EIP point to?However, there are multiple ways to get around it.
3
Getting around stack randomization through indirect jump
4
EIP
Shell Code
NOP sled
ESP
Shell Code
0x42122ba7: JMP ESP (0xffe4)
beginning of the buffer
SomeUseful Points
lddprogram_nameDisplays the dynamically linked libraries and their entrance addressesYou can search the jump code directly in any program’s address space as long as it links the same libraries at the same locations as the target program
5
Thoughts
Any register that points to somewhereafterthe beginning of the vulnerable buffer could work.We can look for the“jump code”by searching the virtual memory space.System libraries are a good place to start.A library’s code may not even have the jump code in its instructions, but we could still find the jump code anyway (Why?).
6
StackGuard
A compile-time mechanism that detects/prevents modification of saved EIP during function execution.When the function starts, a“canary word”is put on the stack in between the function’s local variables and saved EIP.If a local buffer is overrun, the canary will have to be“killed”before the saved EIP can be modified.Before function returns, checks whether the canary is still intact. If not, hand program control to a pre-defined exception handler and terminate the program.
7
canary word
saved EBP
.text
.data
heap malloc’ed data
heap
stack
<
>
function’s argument
saved EIP
main() local variables
bottom of stack
ESP
EBP
address growth
function’s return address
AAAAAAAAAAAAAAAAAAAAAAAAAA
A A A A
A A A A
StackGuard
argc, **argv, **envp
environment var’s
local variables
AAAAAAAAAAAAAAAAAAAAAAAAAA
8
A A A A
Types of Canary
Terminator canaryA character that in most cases will terminate a malicious string,e.g.NULL.Random canaryA random value produced at program execution timeThe random value is stored in a global variableXOR canaryA random value XOR’ed with saved EIPOn function return, the canary is XOR’ed with the random value and the result compared with saved EIP
9
Limitation of StackGuard
Will not work if the exploit does not depend upon modifying saved EIPBuffer overflow in certain stack layouts could give the attacker ability to modify any memory location with any valueThis opens up a number of new options to hijack the program’s control flow,e.g.modify the entrance table of exception handlers or system functionsThe same limitation applies to other similar mechanismse.g.StackShield
10
canary word
saved EBP
.text
.data
heap malloc’ed data
heap
stack
<
>
function’s argument
saved EIP
main() local variables
bottom of stack
ESP
EBP
address growth
AAAAAAAAAAAAAAAAAAAAAAAAAA
Circumvent StackGuard
argc, **argv, **envp
environment var’s
char buf[];char* ptr;
AAAAAAAAAAAAAAAAAAAAAAAAAA
11
function body:…copy(buf, attacker-controlled data);…copy(ptr, attacker-controlled data);…
Modify any memory location (where) with arbitrary data (what).
Non-executable Stack
OS/architecture protection of virtual memory so that injected code cannot runNX/XD bit: mark certain memory pages (e.g. stack pages)non-executable (DEP)W^Xprotection:a page cannot be both writable and executableConsequencesInjected shellcode on the stack cannot be executedDeviates from von-Neumann architecturee.g.run-time code generation may be affected
12
Limitation of non-executable stack
Will not work if the exploit does not rely on code injected on the stack.Code can be injected in other memory segments,e.g.heap.Or no need to inject code at all!
13
Getting around non-executable stack through return-into-libc
14
EIP
entrance address of a libc function
AAAAAAAAAAAAAAAAAAAAAAAAAAAA ????
system(…);
ESP
W1
W2
libc’s return address
libc’s argv[1]
???? ????
“/bin/sh”
entrance address of the next libc function you want to run, e.g., exit();
Thoughts
Whenever a new defense against software exploit is invented, a new way to get around it emerges.These defensive mechanisms are reactive and address a particularway of attack, not the underlyingvulnerability.Nonetheless they provide an important line of defense for software vulnerabilities.To reduce the“attack surface,”we must also address the underlying vulnerabilities.Defensive programmingUsing type-safe languages and static code analysis
15
Implication on System Security
We must assume that software applications will have security vulnerabilities in themProper design of protection mechanisms is essential to mitigate thethreats.
16