Automatic Diagnosis and Response to Memory
Corruption Vulnerabilities
Presenter: Jianyong Dai
Jun Xu, Peng Ning, Chongkyung Kil, Yan Zhai, Chris Bookhot
North Carolina State University
ACM Computer and Communication Security (CCS), 2005
University of Central Florida2/28
Problem Definition
Which statement cause the problem when a memory corruption occurs?
What a conventional debugger can tell you?– Stack trace information
University of Central Florida3/28
Problem Definition
What’s wrong with the debugger?– The location of the error can be just a victim instruction
– We need to identify the vulnerability of the software
– The stack may have been destroyed– It is especially the case in a malicious attack
char a[3];
void (*func) (int);
. .....
strcpy(a, inputline); // inputline = "abcdefg";
......
func(0); Identified by debugger
Actual error
University of Central Florida4/28
Contribution
Proposed a way to automatic diagnosis (partially) the memory corruption caused by vulnerability
Generate signature of the attack to prevent future attack
University of Central Florida5/28
Agenda
Automatic diagnosis
Signature generation
Experimental result
Strength, weakness and extension
University of Central Florida6/28
Agenda
Automatic diagnosis
Signature generation
Experimental result
Strength, weakness and extension
University of Central Florida7/28
Address Space Randomization
Worm infection– Exploit a vulnerability to Inject code and jump to that code– Need to guess the address of injected code
Using address space randomization– Attack can not get the correct address
Normal State
Exploit
Crashguess wrong
guess correct
Normal State Crash
Injected Code
Injected Address
University of Central Florida8/28
Goal of Diagnosis
Goal of Diagnosis– Which is the faulting instruction (direct cause)?– Which is the corrupting instruction (real cause)?
Problem of conventional debugger– Stack may be destroyed– Even stack is good, it can not identify corrupting instruction
The author writes its own exception handler capture the crash and diagnose
University of Central Florida9/28
Critical Point in Vulnerability
Two critical point– Point of exploit (corrupting instruction)
– The program enters an inconsistent state
– Point of takeover– Before that, computer executes code of the software, after that,
computer executes malicious code
void funcA(){
char a[100];.....strcpy(a, inputline); // inputline = "%u9090%u6858%ucbd3......
// %u53ff%u0078%u0000%u00"....return;
}
Exploit
Takeover
University of Central Florida10/28
Four Cases of Corruption
Four cases of crash
TakeoverExploit
Case 1 Case 2 Case 3 Case 4
University of Central Florida11/28
Case 1
Consider format string attack:
– Crash immediately if the speculated address is not legal
char buffer[100];sprintf(buffer, format) // format = "\x54\x74\x04\x08%.500d%n"
Attack need to guess this address
// rightprintf("%s", s); printf(“12345678%n", &x);
// wrong printf(s); // s comes from network input
// if s = "%d", print next variable on stack// more serious// if s = "%n", write the length of the output to next variable on stack
Format string attack
University of Central Florida12/28
Case 2
Consider the following stack smashing attack
Crash after exploit
int* p;char a[100];.....strcpy(a, inputline); ....*p = 1;
Overwrite in an illegal address
Crash
University of Central Florida13/28
Case 3
Consider classic stack smashing
– Crash right at takeover instruction
void funcA(){
char a[100];.....strcpy(a, inputline); // inputline = "%u9090%u6858%ucbd3
// ......%u53ff%u0078%u0000%u00"....return;
}illegal
Crash
University of Central Florida14/28
Case 4
Consider classic stack smashing
– Crash somewhere after takeover instruction
void funcA(){
char a[100];.....strcpy(a, inputline); // inputline = "%u9090%u6858%ucbd3
// ......%u53ff%u0078%u0000%u00"....return;
}void main(){
……funcA();……
Legal though not correct
Can not return here
University of Central Florida15/28
Reduce Case 4
Rerun the program using a complete different memory layout
Legal Illegal
Reduced to case 3
University of Central Florida16/28
Exception Handler
When exception happens, customized exception handle take control
– If PC = CR2– Destination address is illegal– “jump” instruction
– Else– Operant address is illegal– “non-jump” instruction
exception_handler(......, CONTEXT context){
......}
PCEAXEBXECXEDXEBPESI……
CR2
Next Instruction Address
Invalid Memory Address
University of Central Florida17/28
Faulting Instruction
“non-jump” instruction– PC is the next instruction– The instruction right before PC is the faulting instruction
“jump” instruction– PC is the destination instruction– Set breakpoint before each “jump” instruction in whole program
whose destination is PC– Rerun the program, and record occurrence of every breakpoint– The last breakpoint before the crash is the faulting instruction
University of Central Florida18/28
Corrupting Memory
From faulting instruction (direct cause), identify corrupting memory address– jmp [ebx+esi]
– Corrupting memory address: ebx+esi
– ret– Corrupting memory address: top of stack
– mov ebp, [ebx+esi];……; mov eax, [ebp]– Where is ebp come from?
– General case is hard to solve, the author use “binary data dependency” to give a partial answer, leave a complete solution to future research
University of Central Florida19/28
From Corrupting Memory Address to Corrupting Instruction
Set hardware watchpoint register on this memory address– Every memory access to that address will trigger exception– Record the occurrence of these exceptions– The last memory access before crash is the corrupting instruction
University of Central Florida20/28
Agenda
Automatic diagnosis
Signature generation
Experimental result
Strength, weakness and extension
University of Central Florida21/28
Signature
We identify the corrupting memory– Values of corrupting memory must come from the malicious
network input
Corrupting value is the signature– Very short signature– High false positive
mov [ebx+esi], ebp
[ebx+esi] = 0x007853ff
jmp [ebx+esi]
[ebx+esi] = 0x007853ff
University of Central Florida22/28
Correlating Signature with Program State
Associate the signature with program state will reduce false positive rate– Malicious? = contain signature? + in right program state?
Program state– Use stack trace as a proximity of program state– Only effective in a multi-stage attack
readDo_authenticatedDo_authentication
main
Program State
+ 0x007853ff
Message Signature
University of Central Florida23/28
Agenda
Automatic diagnosis
Signature generation
Experimental result
Strength, weakness and extension
University of Central Florida24/28
Experimental Result
Tested Servers
Performance overhead– Expect to reduce to around 10% if move the code into kernel
space
Program Description Vuln/Attack Type
ghttpd web server buffer overflow
rpc.statd NFS stat server format string
openSSH secure shell server integer overflow
Icecast media streaming svr buffer overflow
Samba file and print service buffer overflow
University of Central Florida25/28
Agenda
Automatic diagnosis
Signature generation
Experimental result
Strength, weakness and extension
University of Central Florida26/28
Strength & Weakness
Strength– Detailed analysis of the problem– Experimental result shows this approach is effective in many
server program
Weakness– Did not give a complete solution to identify the corrupting
instruction– The effectiveness of signature and stack trace correlating is still
in doubt
University of Central Florida27/28
Extension
Use single step trace to examine where the corrupting data come from step by step
mov ebp, [ebx+esi]……mov eax, [ebp] Where is ebp come from?
•Rerun the program•Stop after each instruction•Check if bp is changed•The last instruction change ebp is suspicious
University of Central Florida28/28
Question