Chapter 6 Weaknesses Exploited

Chapter 6Weaknesses Exploited

Weaknesses • Bad software is everywhere, and… • …flaws can cause security problems • In this chapter • Various overflow conditions • Format string vulnerabilities • How weaknesses are found • Defenses • Human factors

Technical Weaknesses • Buffer overflow • Process address space: 4 sections • Fixed-sized code block (code/text) • Static data (data) • Dynamic data (heap) • “Scratch paper” (stack)

Technical Weaknesses • C program example

Stack Frame • Stack frame allocated for functions • Stack holds… • Local variables • Book keeping info, such as • Input arguments • Return address • Saved frame pointer, etc.

Stack Frame • Stack frame in action

Memory Organization • low address text • Text== code • Data== static variables • Heap== dynamic data • Stack== “scratch paper” • Dynamic local variables • Parameters to functions • Return address data heap   • SP stack • high address

Simplified Stack Example low  void func(int a, int b){ char buffer[10]; } void main(){ func(1, 2); } : : • SP buffer • SP • return address ret a • SP b • SP high 

Smashing the Stack low  • What happens if buffer overflows? : : ??? • Program “returns” to wrong location • SP buffer • SP overflow ret • ret… NOT! • A crash is likely overflow a • SP b • SP high 

Smashing the Stack low  • Trudy has a better idea… : : • Code injection • Trudy can run code of her choosing… • On your machine! • SP evil code ret ret • SP a • SP b • SP high 

Smashing the Stack : : • Trudy may not know… • Address of evil code • Location of ret on stack • Solutions • Precede evil code with NOP “landing pad” • Insert ret many times NOP : NOP evil code ret ret • ret : ret : :

Stack Smashing • Note that injected code is usually known as “shellcode” • Other overflow attacks are possible • Some inject code, some don’t • We discuss a few more examples later

Stack Smashing Summary • A buffer overflow must exist in the code • Not all buffer overflows are exploitable • Things must align just right • If exploitable, attacker can inject code • Trial and error is likely required • Fear not, lots of help available online • Smashing the Stack for Fun and Profit, Aleph One • Stack smashing is “attack of the decade” • Regardless of the decade… • Also heap overflow, integer overflow, etc.

Stack Smashing Example • Program asks for a serial number that the attacker does not know • Attacker does not have source code • Attacker does have the executable (exe) • Program quits on incorrect serial number

Example • By trial and error, attacker discovers apparent buffer overflow • Note that 0x41 is “A” • Looks like ret overwritten by 2 bytes!

Example • Next, disassemble bo.exe to find • The goal is to exploit buffer overflow to jump to address 0x401034

Example • Find that, in ASCII, 0x401034 is “@^P4” • Byte order is reversed? Why? • X86 processors are “little-endian”

Example • Reverse the byte order to “4^P@” and… • Success! We’ve bypassed serial number check by exploiting a buffer overflow • What just happened? • We overwrote the return address on the stack

Example • Note that in this example… • We overwrote return address and jumped to somewhere interesting • We did not inject any code • Other interesting places to jump to? • Without injecting code, that is? • Often called “return to libc” attacks

Example • Attacker did not require access to the source code • Only tool used was a disassembler to determine address to jump to • Possible to find desired address by trial and error? • Necessary if attacker does not have exe • For example, a remote attack

Example • Source code of the buffer overflow • Flaw easily found by attacker • Without the source code!

Stack Smashing Prevention • 1st choice: employ non-executable stack • “No execute” NX bit (if available) • Seems like the logical thing to do, but some real code executes on the stack (Java, for example) • 2nd choice: use safe languages (Java, C#) • 3rd choice: use safer C functions • For unsafe functions, there are safer versions • For example, strncpy instead of strcpy

Stack Smashing Prevention low  • Canary • Run-time stack check • Push canary onto stack • Canary value: • Constant 0x000aff0d • Or may depends on ret : : buffer overflow canary overflow ret a high  b

Microsoft’s Canary • Microsoft added buffer security check feature to C++ with /GS compiler flag • Based on canary (or “security cookie”) Q: What to do when canary dies? A: Check for user-supplied “handler” • Handler shown to be subject to attack • Claims that attacker can specify handler code • If so, formerly “safe” buffer overflows become exploitable when /GS is used!

ASLR • Address Space Layout Randomization • Randomize place where code loaded in memory • Makes most buffer overflow attacks probabilistic • Vista uses 256 random layouts • So about 1/256 chance buffer overflow works? • Similar thing in Mac and other OSs • Attacks against Microsoft’s ASLR do exist • Possible to “de-randomize”

Buffer Overflow • A major threat yesterday, today, and tomorrow • Can greatly reduced overflow attacks • Use safe languages/safer functions • Educate developers, use tools, etc. • Buffer overflows will exist for a long time • Legacy code • Bad software development practices

Race Condition • Security processes should be atomic • Occur “all at once” • Race conditions can arise when security-critical process occurs in stages • Attacker makes change between stages • Often, between stage that gives authorization, but before stage that transfers ownership • Example:prepaid debit card

Race Condition • Adding cash to card • User inserts card into card reader machine • Machine reads value of card: x • User insert cash into machine: y • User presses “enter” key • Machine writes x+y to card • Machine ejects card • Race condition?

Race Condition • Attacks on cash card protocol? • Insert 2 cards, sandwiched together • Card that is read has $100 value, unread card has $1 value • Step 2: Machine reads x = 100 • Insert $2, so y =2 • Pull out read card, leaving unread one • Press “enter”…

Race Conditions • Race conditions appear to be common in software • May be more common than buffer overflows • But race conditions harder to exploit • Buffer overflow is “low hanging fruit” today • To prevent race conditions… • Make security-critical processes atomic • Occur all at once, not in stages • Not so easy to accomplish in practice

Heap Overflow • Heap used for dynamic variables • For example, malloc in C • Can overflow one array into another • Makes it possible to change data • Like example on next slide

Simple Buffer Overflow • Consider boolean flag for authentication • Buffer overflow could overwrite flag allowing anyone to authenticate! Boolean flag buffer F O U R S C … T F • In some cases, Trudy can be more systematic

Heap Overflow Example • BEFORE: • buf2 = 22222222 • AFTER: • buf2 = 11122222

Heap Overflow • Bookkeeping info stored on heap • Can attacker exploit this?

Heap Overflow • Data structure to keep track of free memory • Assume it is a doubly-linked list • Heap overflow attacks?

Heap Overflow • Here we free block B • “Unlink” B from heap • If overflow in A, can overwrite B’s pointers…

Heap Overflow • Overwrite B’s pointers • Then free B • Now if we ever get to B, will go to shellcode

Integer Overflow • Many “integer” problems • This example… • What if len is negative? • Note that memcpy thinks len is unsigned

Format String Vulnerabilities • Format string example printf(“The magic number is %d\n”, 42); • Format strings:

Format Strings and the Stack • Formatting functions retrieve parameters from the stack • Assuming that’s where they’re stored… • Consider printf(“a has value %d at address %d\n”, a, &a); • What if there are too few arguments? • For example printf(“a has value %d at address %d\n”);

Format Strings and the Stack • Consider again printf(“a has value %d at address %d\n”, a, &a); • Here, x1 and x2 are other things on the stack low  : : “a has … \n” a address of a x1 x2 high 

Format Strings and the Stack • What if there are too few arguments? • For example printf(“a has value %d at address %d\n”); • What happens? low  : : “a has … \n” x1 x2 x3 • Print stuff on stack • Is this useful? x4 high 

Format String Issue 1 • We can “walk” the stack • That is, print out items on the stack • For example printf(“%08x %08x %08x %08x %08x\n”); • As a bonus, it’s nicely formatted…

Format String Issue 2 • What would this do? printf(“%s%s%s%s%s%s%s%s%s%s%s”); • For each %s function printf will… • Fetch a number from the stack • Treat the number as an address • Print out whatever is at that address, until NULL character • Such an “address” might not exist!

Format String Example • What about something like this… void print_error(char *s){ char buffer[100]; snprintf(buffer, sizeof(buffer), “Error: %s”, s); printf(buffer);} • Suppose Trudy has control over what goes into the string s • Then some interesting possibilities…

Format String Issue 3 low  return printf • Suppose Trudy sets string sto \x78\x56\x34\x12 %d%d%d%s • Note \x78…\x12 is little endian for 1234567 • What does code on previous slide do? “Error: %s…” 1st %d 2nd %d : : : : %s 1234567 buffer %d %d : : high  : :

Format String Issue 4 • The %n format is used to print the number of characters written so far • Q: What does this do? inti; printf(“abcde%n, &i); • A: Writes 5 to variable i • Can Trudy take advantage of this?

Format String Issue 4 • Similar attack as “issue 3”… • …except use %n in place of %s • Then a value written to address 1234567 • What value? • Some claim that this allows writing of arbitrary value • Is this really true?

Format String Defenses • Source code auditing • Relatively few format strings • Remove support for %n format • Would this create any problems? • Keep track of number of arguments • General buffer overflow prevention • For example, ASLR (next slide…)

More Defenses • Mentioned by author • NX approach • Canary • ASLR • Safe/safer languages

Chapter 6 Weaknesses Exploited