1. 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

2. 2/28 University of Central Florida Problem Definition Which statement cause the problem when a memory corruption occurs? What a conventional debugger can tell you? –Stack trace information

3. 3/28 University of Central Florida 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

4. 4/28 University of Central Florida Contribution Proposed a way to automatic diagnosis (partially) the memory corruption caused by vulnerability Generate signature of the attack to prevent future attack

5. 5/28 University of Central Florida Agenda Automatic diagnosis Signature generation Experimental result Strength, weakness and extension

6. 6/28 University of Central Florida Agenda Automatic diagnosis Signature generation Experimental result Strength, weakness and extension

7. 7/28 University of Central Florida 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 Crash guess wrong guess correct Normal StateCrash Injected Code Injected Address

8. 8/28 University of Central Florida 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

9. 9/28 University of Central Florida 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

10. 10/28 University of Central Florida Four Cases of Corruption Four cases of crash Takeover Exploit Case 1Case 2Case 3Case 4

11. 11/28 University of Central Florida 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 // right printf("%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

12. 12/28 University of Central Florida 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

13. 13/28 University of Central Florida 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

14. 14/28 University of Central Florida 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

15. 15/28 University of Central Florida Reduce Case 4 Rerun the program using a complete different memory layout Legal Illegal Reduced to case 3

16. 16/28 University of Central Florida 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) {...... } PC EAX EBX ECX EDX EBP ESI …… CR2 Next Instruction Address Invalid Memory Address

17. 17/28 University of Central Florida 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

18. 18/28 University of Central Florida 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

19. 19/28 University of Central Florida 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

20. 20/28 University of Central Florida Agenda Automatic diagnosis Signature generation Experimental result Strength, weakness and extension

21. 21/28 University of Central Florida 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

22. 22/28 University of Central Florida 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 read Do_authenticated Do_authentication main Program State + 0x007853ff Message Signature

23. 23/28 University of Central Florida Agenda Automatic diagnosis Signature generation Experimental result Strength, weakness and extension

24. 24/28 University of Central Florida Experimental Result Tested Servers Performance overhead –Expect to reduce to around 10% if move the code into kernel space ProgramDescriptionVuln/Attack Type ghttpdweb serverbuffer overflow rpc.statdNFS stat serverformat string openSSHsecure shell serverinteger overflow Icecastmedia streaming svrbuffer overflow Sambafile and print servicebuffer overflow

25. 25/28 University of Central Florida Agenda Automatic diagnosis Signature generation Experimental result Strength, weakness and extension

26. 26/28 University of Central Florida 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

27. 27/28 University of Central Florida 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

28. 28/28 University of Central Florida Question