Outline

• Buffer Overflows
• HW Problem
• Incomplete Mediation
• Race Conditions
• Malware

Memory Organization

On Monday, we described how Trudy if she got lucky could use a buffer overflow to authenticate herself. Today, we begin by trying to understand how Trudy can increase her odds. To do that we need to know a little about how memory in a computer process is typically organized.

• Text == code
• Data == static variables
• Heap == dynamic data
• Stack == "scratch paper"
  • Dynamic local variables
  • Parameters to functions
  • Return address

Simplified Stack Example

void func(int a, int b){
    char buffer[10];
}	
void main(){
    func(1, 2);
}

• Here the stack is being used to hold the local variable buffer.
• So if buffer overflows, then the return address is overwritten.
• This would likely cause a crash, or...

Smashing the Stack

• Trudy has a better idea...
• Code injection
• Trudy can run code of her choosing...

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

Stack Smashing Summary

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

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

Buffer Overflow Present?

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

Disassemble Code

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

Buffer Overflow Exploit

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

Overflow Attack, Take 2

• Reverse the byte order to "4^P@" and...
• Success! We've bypassed serial number check by exploiting a buffer overflow
  
• What just happened?
• Overwrote return address on the stack

Buffer Overflow

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

Source Code

• Source code for buffer overflow example
• Flaw easily found by attacker...
• ...without access to source code!

Stack Smashing Defenses

• 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)
• Use a canary
• Address space layout randomization (ASLR)
• Use safe languages (Java, C#)
• Use safer C functions
  • For unsafe functions, safer versions exist
  • For example, strncpy instead of strcpy

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
  • Claim 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
• Windows Vista uses 256 random layouts
  -- So about 1/256 chance buffer overflow works?
• Similar thing in Mac OS X and other OSs
• Attacks against Microsoft's ASLR do exist
  -- Possible to "de-randomize"

Buffer Overflow

• A major security threat yesterday, today, and tomorrow
• The good news?
• It is possible to reduce overflow attacks
  -- Safe languages, NX bit, ASLR, education, etc.
• The bad news?
• Buffer overflows will exist for a long time
  -- Legacy code, bad development practices, etc.

HW Problem

Exercise 11.6. Recall that a canary is a special value that is pushed onto the stack after the return address.

(a) How is a canary used to prevent stack smashing attacks?

Answer. A canary is used together with run time stack checking. The run time stack checking system is invoked when the return address is popped off the stack. The system checks that before the return address a "canary" byte string still exists. This byte string often contains characters like \0 to prevent a string from overrunning the stack data. If it doesn't exist an error state is gone into.

(b) How was Microsoft's implementation of this technique, the /GS compiler option flawed?