1 / 28

Intro to Exploitation Stack Overflows

Intro to Exploitation Stack Overflows. James McFadyen UTD Computer Security Group 10/20/2011. Intro to Exploitation. Only an intro to stack overflow Basic theory and application One of many types of exploitation. Outline. What is a buffer overflow? Tools Vulnerable C Functions

cmorrell
Télécharger la présentation

Intro to Exploitation Stack Overflows

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Intro to Exploitation Stack Overflows James McFadyen UTD Computer Security Group 10/20/2011

  2. Intro to Exploitation • Only an intro to stack overflow • Basic theory and application • One of many types of exploitation

  3. Outline • What is a buffer overflow? • Tools • Vulnerable C Functions • Remember the memory • Learn to love assembly • Stack overflow • Protection Mechanisms • ret2libc in Linux

  4. Buffer Overflow • “In computer security and programming, a buffer overflow, or buffer overrun, is an anomaly where a program, while writing data to a buffer, overruns the buffer's boundary and overwrites adjacent memory. This is a special case of violation of memory safety.” - Wikipedia

  5. Buffer Overflow • In our examples.. • Give the program too much input, hijack the instruction pointer (EIP) • Control EIP • Execute arbitrary code locally or remotely • Achieve what we want as elevated user

  6. Tools • Linux • GDB, gcc, vi, perl/python/ruby, readelf, objdump, ltrace, strace, ropeme • Windows • WinDBG, OllyDBG, ImmunityDBG, IDA, Python, Mona (ImmunityDBG plugin)

  7. Vulnerable C Code • strcpy(), strncpy() • strcat(), strncat() • sprintf(), snprintf() • gets() • sscanf() • Many others...

  8. Vulnerable C Code • strcpy() doesn't check size • If we have char buf[128]; strcpy(buf, userSuppliedString); • This makes it too easy...

  9. Vulnerable C Code • char *strncpy(char *dest, const char *src, size_t n); • We have a size, but what if.. strncpy(somebuffer, str, strlen(str)); • or.. strncpy(somebuffer, str, sizeof(somebuffer)); • Where str is supplied by user

  10. Vulnerable C Code • Common bug, proper fix: strncpy(somebuffer, str, sizeof(somebuffer)-1);

  11. Vulnerable C Code • char *strncat(char *dest, const char *src, size_t n); • Ex: int vulnerable(char *str1, char *str2) { char buf[256]; strncpy(buf, str1, 100); strncat(buf, str2, sizeof(buf)-1); return; }

  12. Vulnerable C Code • Fix: strncat(buf, str2, sizeof(buf) - strlen(buf) -1);

  13. Remember the Memory Low Text Code segment, machine instr. Initialized global and static variables Data Uninitialized global and static variables BSS Heap Dynamic space. malloc(...) / free(...) new(...) / ~ Program scratch space. Local variables, pass arguments, etc.. Stack High * Taken from Mitchell Adair's “Stack Overflows”

  14. Remember the Memory: The Stack Low ESP local variables ... EBP - x EBP EBP RET EBP + x arguments... previous stack frame High * Taken from Mitchell Adair's “Stack Overflows”

  15. Love the Assembly EIP – Extended Instruction Pointer Next Instruction executed ESP – Extended Stack Pointer Top of stack EBP – Extended Base Pointer Base Pointer EAX Accumulatorregister EBX Base register ECX Counter register EDX Data register ESI Source index EDI Destination Index * Taken from Mitchell Adair's “Stack Overflows”

  16. Stack Overflow ESP char buf[100] 100 bytes EBP EBP 4 bytes RET 4 bytes argc *argv[] * Taken from Mitchell Adair's “Stack Overflows”

  17. Stack Overflow Ex: $ ./program $(python -c 'print "A" * 108 ') ESP RET overwritten Ret will pop the instruction pointer off of the stack EIP will now point to 0x41414141 108 bytes ( 0x41 * 108) 100 bytes EBP EBP 4 bytes RET RET 4 bytes argc *argv[] * Taken from Mitchell Adair's “Stack Overflows”

  18. Stack Overflow Ex: $ ./program $(python -c 'print "A" * 104 + “\xef\xbe\xad\xde” ') ESP 0xdeadbeef EIP will now point to 0xdeadbeef We can now point EIP where we want 104 bytes ( 0x41 * 104 100 bytes EBP EBP 4 bytes RET RET 4 bytes argc *argv[] * Taken from Mitchell Adair's “Stack Overflows”

  19. Stack Overflow • $ ./program $(python -c 'print "A" * 104 + “\xef\xbe\xad\xde” ') • We have 104 bytes for a payload • Payload can be anything, but for our purpose we would spawn a shell • The payload will be fixed size, so when we insert it, we must reduce the # of A's by the size of the payload

  20. Stack Overflow • $ ./program $(python -c 'print "A" * 104 + “\xef\xbe\xad\xde” ') • If we had a 32 byte payload .. (real payload will not be a bunch of \xff) $ ./program $(python -c 'print "A" * 72 + “\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff” + “\xef\xbe\xad\xde” ') • We have adjusted the buffer so the payload will fit • We will then have to point EIP (\xef\xbe\xad\xde) to our payload on the stack

  21. Stack Overflow • $ ./program $(python -c 'print "A" * 72 + “\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff” + “\xef\xbe\xad\xde” ') • “\xef\xbe\xad\xde” would be replaced with the address of our payload • EIP will now point to the address of our payload, which will spawn a shell • NOPs help create a bigger “landing area” • This technique is not very effective anymore... why?

  22. Protection Mechanisms (Windows) • DEP – Data execution Prevention • Can't execute on the stack • /GS Flag – cookie / canary • detects if stack has been altered • SafeSEH – Structured Exception Handler • Try / except, catches exceptions • ASLR - Address Space Layout Randomization • Randomizes addresses in memory

  23. Protection Mechanisms (Linux) • NX – Stack Execute Invalidation • Processor feature • Like DEP, can't execute on the stack • Stack Smashing Protection – cookie / canary • Generally enabled by default • ASLR - Address Space Layout Randomization • Many other compiler protections...

  24. ret2libc • Bypasses NX • Point EIP to a function in libc • system(), exec() etc... • system(“/bin/sh”); • We will get a shell by using the system() function in libc

  25. ret2libc $ ./program $(python -c 'print "A" * 104 + “\xef\xbe\xad\xde” ') • We don't need the payload where the A's are anymore • We now will point EIP to the address of system(), then the next 4 bytes will be a return address, followed by system() arguments (which will be /bin/sh) $ ./program $(python -c 'print "A" * 104 + address_of_system + return_address + payload ')

  26. Demo! • How to use GDB for exploitation • Exploring the stack • Finding important memory addresses (ret2libc) • Breakpoints • Using Perl/Python/Ruby for arguments in GDB • Basic Stack Overflow • Ret2libc

  27. Additional Resources • https://www.corelan.be/index.php/articles/ • http://beej.us/guide/bggdb/ • http://en.wikibooks.org/wiki/X86_Assembly • http://www.alexonlinux.com/how-debugger-works • http://smashthestack.org/ • http://intruded.net/

  28. Sources • “Source Code Auditing” - Jared Demott • “Smashing the stack in 2010” - Andrea Cugliari + Mariano Graziano • “Stack Overflows” - Mitchell Adair • http://en.wikipedia.org/wiki/Buffer_overflow • http://en.wikipedia.org/wiki/Return-to-libc_attack

More Related