Software and Security Buffer Overflow 1 Why Software

Software and Security Buffer Overflow 1

Why Software? Why is software important to security? q Virtually all of information security is implemented in software q If your software is subject to attack, your security is broken q o Regardless of strength of crypto, access control, security protocols, etc. q Software is a poor foundation for security Buffer Overflow 2

Bad Software q q Bad software is everywhere! NASA Mars Lander (cost $165 million) o Crashed into Mars o Error in converting English and metric units of measure q Denver airport o Buggy baggage handling system o Delayed airport opening by 11 months o Cost of delay exceeded $1 million/day q MV-22 Osprey o Advanced military aircraft o Lives have been lost due to faulty software Buffer Overflow 3

Software Issues “Normal” users q Find bugs and flaws by accident q Hate bad software… q …but must learn to live with it q Must make bad software work Buffer Overflow Attackers q Actively look for bugs and flaws q Like bad software… q …and try to make it misbehave q Attack systems thru bad software 4

Complexity q “Complexity is the enemy of security”, Paul Kocher, Cryptography Research, Inc. system Netscape 17, 000 Space shuttle 10, 000 Linux q Lines of code (LOC) 1, 500, 000 Windows XP 40, 000 Boeing 777 7, 000 A new car contains more LOC than was required to land the Apollo astronauts on the moon Buffer Overflow 5

Lines of Code and Bugs Conservative estimate: 5 bugs/1000 LOC q Do the math q Typical computer: 3, 000 exe’s of 100 K each Conservative estimate of 50 bugs/exe About 150 k bugs per computer 30, 000 node network has 4. 5 billion bugs Suppose that only 10% of bugs security-critical and only 10% of those remotely exploitable o Then “only” 4. 5 million security-critical flaws! o o o Buffer Overflow 6

Software Security Topics q Program flaws (unintentional) o Buffer overflow o Incomplete mediation o Race conditions q Malicious software (intentional) o Viruses o Worms o Other breeds of malware Buffer Overflow 7

Secure Software In software engineering, try to insure that a program does what is intended q Secure software engineering requires that the software does what is intended… q …and nothing more q Absolutely secure software is impossible q o Absolute security is almost never possible! q How can we manage the risks? Buffer Overflow 8

Program Flaws q Program flaws are unintentional o But still create security risks q The 3 most common types of flaws o Buffer overflow (smashing the stack) o Incomplete mediation o Race conditions Many other flaws can occur q Here, we only consider buffer overflow q Buffer Overflow 9

Buffer Overflow 10

Typical Attack Scenario Users enter data into a Web form q Web form is sent to server q Server writes data to buffer, without checking length of input data q Data overflows from buffer q Sometimes, overflow can enable an attack q Web form attack could be carried out by anyone with an Internet connection q Buffer Overflow 11

Buffer Overflow int main(){ int buffer[10]; buffer[20] = 37; } Q: What happens when this is executed? q A: Depending on what resides in memory at location “buffer[20]” q o Might overwrite user data or code o Might overwrite system data or code Buffer Overflow 12

Simple Buffer Overflow Consider boolean flag for authentication q Buffer overflow could overwrite flag allowing anyone to authenticate! q Boolean flag buffer F OU R S C q … T F In some cases, attacker need not be so lucky as to have overflow overwrite flag Buffer Overflow 13

Memory Organization Text == code q Data == static variables q Heap == dynamic data q Stack == “scratch paper” q o Dynamic local variables o Parameters to functions o Return address Buffer Overflow text ¬ low address data heap stack ¬ SP ¬ high address 14

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

Smashing the Stack low q What happens if buffer overflows? : ? ? ? : q Program “returns” to wrong location q. A buffer crash is likely overflow ret overflow a high Buffer Overflow b ¬ SP ret… NOT! ¬ SP 16

Smashing the Stack q Trudy has a better idea… low : : q Code injection q Trudy can run code of her choosing! evil code high Buffer Overflow ¬ SP ret ¬ SP a b ¬ SP 17

Smashing the Stack q Trudy may not know o Address of evil code o Location of ret on stack q Solutions o Precede evil code with NOP “landing pad” o Insert lots of new ret Buffer Overflow : : NOP evil code ret : : ¬ ret 18

Stack Smashing Summary A buffer overflow must exist in the code q Not all buffer overflows are exploitable q o Things must line up just right If exploitable, attacker can inject code q Trial and error likely required q o Lots of help available online o Smashing the Stack for Fun and Profit, Aleph One Also heap overflow, integer overflow, etc. q Stack smashing is “attack of the decade” q Buffer Overflow 19

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

Example q By trial and error, attacker discovers an apparent buffer overflow Note that 0 x 41 is “A” q Looks like ret overwritten by 2 bytes! q Buffer Overflow 21

Example q Next, disassemble bo. exe to find q The goal is to exploit buffer overflow to jump to address 0 x 401034 Buffer Overflow 22

Example q Find that 0 x 401034 is “@^P 4” in ASCII Byte order is reversed? Why? q X 86 processors are “little-endian” q Buffer Overflow 23

Example q Reverse the byte order to “ 4^P@” and… Success! We’ve bypassed serial number check by exploiting a buffer overflow q Overwrote the return address on the stack q Buffer Overflow 24

Example q Attacker did not require access to the source code q Only tool used was a disassembler to determine address to jump to q Can find address by trial and error o Necessary if attacker does not have exe o For example, a remote attack Buffer Overflow 25

Example q Source code of the buffer overflow q Flaw easily found by attacker q Even without the source code! Buffer Overflow 26

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

Stack Smashing Prevention low : : q Canary o Run-time stack check o Push canary onto stack o Canary value: buffer overflow canary overflow ret § Constant 0 x 000 aff 0 d § Or value depends on ret high Buffer Overflow ¬ a b 28

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

ASLR q Address Space Layout Randomization q Randomize place where code is put into memory q Makes most buffer overflow attacks probabilistic q Vista does this (256 random layouts) o Similar thing is done in Mac OS X Buffer Overflow 30

ASLR q See work by Ulfar Erlingsson o Slides can be found here Buffer Overflow 31

Buffer Overflow The “attack of the decade” for 90’s q Will be the attack of the decade for 00’s q Can be greatly reduced q o Use safe languages/safer functions o Educate developers, use tools, etc. q Buffer overflows will exist for a long time o Legacy code o Bad software development Buffer Overflow 32