1 / 57

Chapter 6 Weaknesses Exploited

Chapter 6 Weaknesses 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

marlis
Download Presentation

Chapter 6 Weaknesses Exploited

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. Chapter 6Weaknesses Exploited

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

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

  4. Technical Weaknesses • C program example

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

  6. Stack Frame • Stack frame in action

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

  8. 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 

  9. 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 

  10. 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 

  11. 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 : :

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

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

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

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

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

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

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

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

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

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

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

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

  24. 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!

  25. 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”

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

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

  28. 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?

  29. 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”…

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

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

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

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

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

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

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

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

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

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

  40. 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”);

  41. 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 

  42. 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 

  43. 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…

  44. 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!

  45. 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…

  46. 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  : :

  47. 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?

  48. 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?

  49. 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…)

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

More Related