automatic diagnosis and response to memory corruption vulnerabilities presenter: jianyong dai jun...

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


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


Contribution

Proposed a way to automatic diagnosis (partially) the memory corruption caused by vulnerability

Generate signature of the attack to prevent future attack


Agenda

Automatic diagnosis

Signature generation

Experimental result

Strength, weakness and extension


Agenda

Automatic diagnosis


Experimental result



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


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


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


Four Cases of Corruption

Four cases of crash

TakeoverExploit

Case 1 Case 2 Case 3 Case 4


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


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


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


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


Reduce Case 4

Rerun the program using a complete different memory layout

Legal Illegal

Reduced to case 3


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


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


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


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


Agenda

Automatic diagnosis


Experimental result



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


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


Agenda

Automatic diagnosis


Experimental result



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


Agenda

Automatic diagnosis


Experimental result



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


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


Question

automatic diagnosis and response to memory corruption vulnerabilities presenter: jianyong dai jun...

Documents

inputline inputline

destroyedeven stack

softwarethe stack

classic stack smashingcrash

address rightprintf

speculated address

stack trace information

format format