Introduction Buffer Overflows Buffer overflows were the most common - PDF document

Introduction Buffer Overflows ♦ Buffer overflows were the most common form of security vulnerability in the 90’s. ♦ Buffer overflows dominate in the area of remote network penetration vulnerabilities. CS 465 ♦ They represent one of the most serious Dr. Kent E. Seamons classes of security threats. – An attacker can gain partial or total control of a Source: “Buffer Overflows: Attacks and Defenses for the Vulnerability of the Decade” Cowan et al. host CS 465 Fall 2001 1 CS 465 Fall 2001 2 Buffer Overflow Attacks Buffer Overflows ♦ Form the substantial portion of all security ♦ Goal of buffer overflow attacks – Subvert the function of a privileged program to – Common take control of the program – Easy to exploit ♦ Dominate remote penetration attacks – If the program is sufficiently privileged, thence control of the host – 1998 CERT advisories, 9 of 13 – Typically the attacker is attacking a root – 1999 CERT advisories, 50 % program, and immediately executes code – Bugtraq survey: 2/3 reported buffer overflows a similar to “exec(sh)” to get a root shell leading cause of security vulnerability CS 465 Fall 2001 3 CS 465 Fall 2001 4 Load Code in Program’s Address Buffer Overflows - Goals Space ♦ Arrange for suitable code to be available in the program’s address space ♦ Inject code ♦ Get the program to jump to that code, with ♦ Use code already in program’s address suitable parameters loaded into registers & space memory CS 465 Fall 2001 5 CS 465 Fall 2001 6 1

Inject code in Address Space Use existing program code ♦ Attacker provides a string as input to the program, which the program stores in a buffer. ♦ Often, the code to do what the attacker ♦ The string contains bytes that are native CPU wants is already present in the program’s instructions address space (“exec(arg)”) – The attacker does not have to overflow any buffers to ♦ The attacker need only parameterize the do this code and jump to it – Buffer can be located anywhere • Stack (automatic variables) • Heap – (malloc’d variables) • Static data area (initialized or uninitialized) CS 465 Fall 2001 7 CS 465 Fall 2001 8 Ways to Cause the Program to Kind of Program State Jump to the Attacker’s Code Overflowed ♦ Alter the program’s control flow so that the ♦ Activation records program will jump to the attack code ♦ Function pointers ♦ Basic method: overflow a buffer that has weak or ♦ Longjmp pointers non-existent bounds checking on its input with a goal of corrupting the state of an adjacent part of the program’s state ♦ The attacker overwrites the adjacent program state with a near arbitrary sequence of bytes ♦ Bypass of C’s type system and the victim program’s logic CS 465 Fall 2001 9 CS 465 Fall 2001 10 Activation Records Function Pointers ♦ Created on the stack when a function is ♦ Function pointers can be allocated called anywhere ♦ Overflow automatic variables ♦ Attacker finds an overflowable buffer ♦ Corrupt the return address in the activation adjacent to a function pointer in any of these areas record ♦ Change the function pointer ♦ “Stack smashing attack” ♦ Majority of current buffer overflow attacks CS 465 Fall 2001 11 CS 465 Fall 2001 12 2

Combining Code Injection and Longjmp Buffers Control Flow Corruption ♦ Checkpoint/rollback facility in C ♦ The simplest and most common form of overflow combines an injection technique and activation ♦ Checkpoint – “setjmp(buffer)” record corruption in a single string –stack ♦ Rollback – “longjmp(buffer)” smashing attack ♦ The injection and corruption do not have to ♦ Attacker can corrupt the state of the buffer happen in one action so that longjmp will jump to the attacker’s – An overflowable buffer may have incorrect bounds code checking, so there is a limit on the overflow that does not give the attacker enough room to store the code – The attacker is using already-resident code • libc code fragments (exec(something)) CS 465 Fall 2001 13 CS 465 Fall 2001 14 Buffer Overflow Defenses Write Correct Code ♦ Write correct code ♦ A laudable but expensive proposition – C language has error-prone idioms such as null- ♦ Non-executable buffers terminated strings and a culture that favors performance ♦ Array Bounds checking over correctness ♦ Automatic search of source code for highly ♦ Code pointer integrity checking vulnerable library calls ♦ Program linking warning messages ♦ Audit teams that review code by hand – lprm program had an error following a code audit CS 465 Fall 2001 15 CS 465 Fall 2001 16 Non-executable buffers Array Bounds Checking ♦ Completely stops buffer overflows ♦ Make the data segment of a program’s address ♦ All reads and writes to arrays must be checked space non-executable ♦ Compaq C compiler – Older computing systems followed this design – Limited bounds checking – Unix and MS -Windows depend on the ability to emit ♦ Gcc patch dynamic code into program data segments – Not mature, complex programs fail ♦ One can make the stack segment non-executable ♦ Purify and preserve most program compatibility – Code instrumentation – Kernel patches available for Linux and Solaris – Imposes a 3 to 5 times slowdown ♦ Linux exceptions to executable code on the stack ♦ Type safe languages – Signal delivery – gcc trampolines – fallen into disuse CS 465 Fall 2001 17 CS 465 Fall 2001 18 3

Type Safe Languages Code pointer integrity checking ♦ All buffer overflows result from a lack of ♦ Instead of preventing corruption of code pointers, type safety in C try to detect a code pointer has been corrupted ♦ Recommendation: write new security before it is de-referenced sensitive code in a type safe language such ♦ Disadvantages as Java or ML – Does not perfectly solve the buffer overflow problem ♦ Advantages – Millions of lines of legacy code – Performance – The JVM is a C program, subject to buffer – Compatibility overflow vulnerabilities – Implementation effort CS 465 Fall 2001 19 CS 465 Fall 2001 20 Code Pointer Integrity StackGuard ♦ Hand-coded stack inspection ♦ Compiler technique implemented as a small patch to gcc that enhances code generation for the code ♦ Compiler-generated activation record to setup and tear down functions integrity checking ♦ Places a canary word next to the return address on ♦ Compiler-generated code pointer integrity the stack ♦ The code checks to see that the canary word is checking intact before jumping to the return address ♦ Invariant – the return address should not change while a function is active CS 465 Fall 2001 21 CS 465 Fall 2001 22 Canary Forgery Prevention PointGuard ♦ Generalizes the StackGuard approach to ♦ Terminator canary defend against alterations to any code – Canary word contains common termination pointer symbols ♦ Places a canary word next to all code ♦ Random canary pointers – The canary is a 32-bit random number chosen ♦ The code checks to see that the canary word at run-time. is intact whenever a code pointer is dereferenced CS 465 Fall 2001 23 CS 465 Fall 2001 24 4