1 / 17

Beyond Stack Smashing: Recent Advances in Exploiting Buffer Overruns

Beyond Stack Smashing: Recent Advances in Exploiting Buffer Overruns. Muhammad Shirjeel Alam (IMSE Cohort IV). Overview. Buffer Overruns Basics Techniques Stack Smashing Arc Injection (Return-To- Libc ) Pointer Subterfuge Function-pointer Clobbering Data Pointer Modification

kaz
Download Presentation

Beyond Stack Smashing: Recent Advances in Exploiting Buffer Overruns

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. Beyond Stack Smashing: Recent Advances in Exploiting Buffer Overruns Muhammad ShirjeelAlam (IMSE Cohort IV)

  2. Overview • Buffer Overruns • Basics • Techniques • Stack Smashing • Arc Injection (Return-To-Libc) • Pointer Subterfuge • Function-pointer Clobbering • Data Pointer Modification • Exception-handler Hijacking • VPTR Smashing • Heap Smashing • Conclusions

  3. What is a Buffer Overrun? When a program attempts to read or write beyond the end of a bounded array (also known as a buffer) Typically, attackers use this to modify a return address saved on the stack to point to code residing in a stack buffer at a known location

  4. Examples • Stack Buffer Overrun void f1a (void * arg, size_t len) { char buff[100]; memcpy(buf, arg, len) /* buffer overrun if len > 100 */ … return } • Heap Buffer Overrun void f1b ( void * arg, size_t len){ char * ptr = malloc(100); if (ptr == NULL_ return; memcpy(ptr, arg, len); /* buffer overrun if len > 100 */ … return; }

  5. How does it work? void function(char *str) { char buffer[16]; strcpy(buffer,str); } Top of stack buffer sfp ret *strBottom of stack [ ][ ][ ][….]

  6. How does it work? – cont’d int main (){ char large_string[256]; ..fill ‘large_string’. function(large_string); } Top of stack buffer sfpret *strBottom of stack [sssssssssss][ssss][0xD8][….]

  7. Stack Smashing void f1a (void * arg, size_tlen) { char buff[100]; memcpy(buf, arg, len) /* buffer overrun if len > 100 */ … return } • Attacker must provide a value for argthat contains an executable payload and the return address will be changed to that of the payload (the address of buff). • Program control is transferred to buff rather than returning to the calling procedure.

  8. Stack Smashing -- Enhancements • Trampolining • If buff’s absolute address is not known ahead of time, an attacker can use a program register R containing a value relative to buff by first transferring control to a sequence of instructions that indirectly transfers via R. • Find the address on the stack using instructions pop/pop/return • Separating payload (attacker’s code) from the buffer overrun operation. • Storing code in an environment variable • Good for overrunning small buffers

  9. Arc Injection • Attacker supplies data that, when a program operates on that data, causes a desired (by the attacker) effect. • Uses a stack buffer overrun to modify return address to point to a location already in the program’s address space. • Usually the system function in the C stdlib. • Useful when the program has non-executable stacks

  10. Arc Injection void system(char*arg) { check_validity(arg); R = arg; Arrange for R to point to user‐supplied data … target: exec } l(R, …) The address of “target” is known

  11. Pointer Subterfuge • Involves modifying a pointer’s value. • Many different attacks • Function-pointer Clobbering • Data Pointer Modification • Exception-handler Hijacking • VPTR Smashing

  12. Function-pointer Clobbering • Modifying a function pointer to point to attackers code. void f3 (void * arg, size_tlen){ char buff[100]; void (*f) () = …; memcpy(buff, arg, len); /* buffer overrun */ f(); …return; } • Use overrun to set f to buff, and call will send control to code in buff • Can combine with Arc Injection to point F to system call.

  13. Data-pointer modification void f4(void * arg, size_t len){ char buff[100]; long val = …; long *ptr = …; extern void (*f)(); memcpy(buff, arg, len) /* overrun! */ *ptr = val; f(); … return;} • Allows attacker to modify memory locations • Can use *ptr = val to assign any 4 bytes of memory

  14. Exception-handler hijacking • When an exception is generated, Windows examines a linked list of exception handlers (registered by program when it starts) and invokes one or more of them via function pointers stored in the list. Because the list entries are stored on the stack, it is possible to replace the exception-handler function pointer with a buffer overflow. • The known variations of this vulnerability are supposedly fixed in WindowsXP SP2.

  15. VPTR Smashing • VTBL (associated with each class) is an array of function pointers used at runtime to implement dynamic dispatch. • Objects point to appropriate VTBL with virtual pointers (VPTR) stored as part of the object’s header. Replacing the VPTR with a pointer to an attacker supplied VTBL transfers control when the next virtual function is invoked. • Can apply to both stack and heap overruns

  16. Heap smashing • Allocators keep headers for each heap block chained together in a doubly linked list of allocated and freed blocks. • If you have three adjacent blocks X, Y, Z; an overrun of X into Y can corrupt pointers in Y’s header, and lead to modification of arbitrary memory locations when Y is freed. • More complicated because: • Attacker typically doesn’t know the heap block’s location ahead of time • Difficult to predict when heap-free operation will occur. • Difficult (especially in with multiple threads) to predict whether the next block has been allocated at time of overrun.

  17. Conclusions • Buffer overruns are likely to be continued source of potential vulnerabilities. • New techniques invalidate old assumptions: • Arc injection needs no injected code • Pointer subterfuge doesn’t overwrite return addresses • Heap smashing and pointer subterfuge show that its not only the stack that’s vulnerable. • Developers need to be cautious of ‘assumptions’. • Arms race continues.

More Related