Software Why Software?
Total Page:16
File Type:pdf, Size:1020Kb
Why Software? ❑ Why is software as important to security Part IV: Software as crypto, access control, protocols? ❑ Virtually all information security features are implemented in software ❑ If your software is subject to attack, your security can be broken o Regardless of strength of crypto, access control, or protocols ❑ Software is a poor foundation for security Part 4 ⎯ Software 1 Part 4 ⎯ Software 2 Chapter 11: Bad Software is Ubiquitous Software Flaws and Malware ❑ NASA Mars Lander (cost $165 million) If automobiles had followed the same development cycle as the computer, o Crashed into Mars due to… o …error in converting English and metric units of measure a Rolls-Royce would today cost $100, get a million miles per gallon, o Believe it or not and explode once a year, killing everyone inside. ⎯ Robert X. Cringely ❑ Denver airport o Baggage handling system ⎯ very buggy software o Delayed airport opening by 11 months My software never has bugs. It just develops random features. o Cost of delay exceeded $1 million/day ⎯ Anonymous o What happened to person responsible for this fiasco? ❑ MV-22 Osprey o Advanced military aircraft o Faulty software can be fatal Part 4 ⎯ Software 3 Part 4 ⎯ Software 4 Complexity Software Issues ❑ “Complexity is the enemy of security”, Paul Kocher, Cryptography Research, Inc. Alice and Bob Trudy ❑ Find bugs and flaws ❑ Actively looks for System Lines of Code (LOC) Netscape 17 million by accident bugs and flaws Space Shuttle 10 million ❑ Hate bad software… ❑ Likes bad software… Linux kernel 2.6.0 5 million ❑ …but they learn to ❑ …and tries to make Windows XP 40 million Mac OS X 10.4 86 million live with it it misbehave Boeing 777 7 million ❑ Must make bad ❑ Attacks systems via software work bad software ❑ A new car contains more LOC than was required to land the Apollo astronauts on the moon Part 4 ⎯ Software 5 Part 4 ⎯ Software 6 Lines of Code and Bugs Software Security Topics ❑ Conservative estimate: 5 bugs/10,000 LOC ❑ Program flaws (unintentional) ❑ Do the math o Buffer overflow o Typical computer: 3k exe’s of 100k LOC each o Incomplete mediation o Conservative estimate: 50 bugs/exe o Race conditions o Implies about 150k bugs per computer ❑ Malicious software (intentional) o So, 30,000-node network has 4.5 billion bugs o Viruses o Maybe only 10% of bugs security-critical and o Worms only 10% of those remotely exploitable o Other breeds of malware o Then “only” 45 million critical security flaws! Part 4 ⎯ Software 7 Part 4 ⎯ Software 8 Example Program Flaws char array[10]; ❑ An error is a programming mistake for(i = 0; i < 10; ++i) array[i] = `A`; o To err is human array[10] = `B`; ❑ An error may lead to incorrect state: fault ❑ This program has an error o A fault is internal to the program ❑ This error might cause a fault ❑ A fault may lead to a failure, where a o system departs from its expected behavior Incorrect internal state o A failure is externally observable ❑ If a fault occurs, it might lead to a failure o Program behaves incorrectly (external) error fault failure ❑ We use the term flaw for all of the above Part 4 ⎯ Software 9 Part 4 ⎯ Software 10 Secure Software Program Flaws ❑ In software engineering, try to ensure that ❑ Program flaws are unintentional a program does what is intended o But can still create security risks ❑ Secure software engineering requires that software does what is intended… ❑ We’ll consider 3 types of flaws ❑ …and nothing more o Buffer overflow (smashing the stack) ❑ Absolutely secure software? Dream on… o Incomplete mediation o Absolute security anywhere is impossible o Race conditions ❑ How can we manage software risks? ❑ These are the most common flaws Part 4 ⎯ Software 11 Part 4 ⎯ Software 12 Attack Scenario Buffer Overflow ❑ Users enter data into a Web form ❑ Web form is sent to server ❑ Server writes data to array called buffer, without checking length of input data ❑ Data “overflows” buffer o Such overflow might enable an attack o If so, attack could be carried out by anyone with Internet access Part 4 ⎯ Software 13 Part 4 ⎯ Software 14 Buffer Overflow Simple Buffer Overflow int main(){ ❑ Consider boolean flag for authentication int buffer[10]; buffer[20] = 37;} ❑ Buffer overflow could overwrite flag allowing anyone to authenticate Boolean flag ❑ Q: What happens when code is executed? ❑ A: Depending on what resides in memory buffer at location “buffer[20]” F O U R S C … TF o Might overwrite user data or code o Might overwrite system data or code ❑ In some cases, Trudy need not be so lucky o Or program could work just fine as in this example Part 4 ⎯ Software 15 Part 4 ⎯ Software 16 Memory Organization Simplified Stack Example ← low low → ❑ Text ⎯ code text address ❑ Data ⎯ static variables void func(int a, int b){ data : char buffer[10]; : ❑ Heap ⎯ dynamic data heap } void main(){ ❑ Stack ⎯ “scratch paper” ↓ ← stack func(1,2); ← SP o Dynamic local variables buffer pointer (SP) } ↑ o Parameters to functions ret ← returnSP stack ← high address o Return address address a ← SP ← high → b SP Part 4 ⎯ Software 17 Part 4 ⎯ Software 18 Smashing the Stack Smashing the Stack low → low → ❑ Trudy has a ❑ What happens if ??? : better idea… : : : buffer overflows? ❑ Code injection ❑ Program “returns” ← SP ❑ Trudy can run ← SP buffer to wrong location code of her evil code overflowret ← ret…SP NOT! retret ← SP ❑ A crash is likely choosing… ← SP ← SP overflowa o …on your machine a ← ← high → b SP high → b SP Part 4 ⎯ Software 19 Part 4 ⎯ Software 20 Smashing the Stack Stack Smashing Summary ❑ A buffer overflow must exist in the code : : ❑ Trudy may not know… ❑ Not all buffer overflows are exploitable NOP o Things must align properly 1) Address of evil code : ❑ If exploitable, attacker can inject code 2) Location of ret on stack NOP ❑ Trial and error is likely required ❑ Solutions evil code o Fear not, lots of help is available online 1) Precede evil code with ret o Smashing the Stack for Fun and Profit, Aleph One NOP “landing pad” ret ← ret ❑ Stack smashing is “attack of the decade”… : o …for many recent decades 2) Insert ret many times ret o Also heap & integer overflows, format strings, etc. : Part 4 ⎯ Software : 21 Part 4 ⎯ Software 22 Stack Smashing Example Buffer Overflow Present? ❑ By trial and error, Trudy discovers ❑ Suppose program asks for a serial number apparent buffer overflow that Trudy does not know ❑ Also, Trudy does not have source code ❑ Trudy only has the executable (exe) ❑ Note that 0x41 is ASCII for “A” ❑ Program quits on incorrect serial number ❑ Looks like ret overwritten by 2 bytes! Part 4 ⎯ Software 23 Part 4 ⎯ Software 24 Disassemble Code Buffer Overflow Attack ❑ Next, disassemble bo.exe to find ❑ Find that, in ASCII, 0x401034 is “@^P4” ❑ The goal is to exploit buffer overflow ❑ Byte order is reversed? What the … to jump to address 0x401034 ❑ X86 processors are “little-endian” Part 4 ⎯ Software 25 Part 4 ⎯ Software 26 Overflow Attack, Take 2 Buffer Overflow ❑ Reverse the byte order to “4^P@” and… ❑ Trudy did not require access to the source code ❑ Only tool used was a disassembler to determine address to jump to ❑ Success! We’ve bypassed serial number ❑ Find desired address by trial and error? check by exploiting a buffer overflow o Necessary if attacker does not have exe ❑ What just happened? o For example, a remote attack o Overwrote return address on the stack Part 4 ⎯ Software 27 Part 4 ⎯ Software 28 Source Code Stack Smashing Defenses ❑ Source code for buffer overflow example ❑ Employ non-executable stack o “No execute” NX bit (if available) ❑ Flaw easily o Seems like the logical thing to do, but some real exploited by code executes on the stack (Java, for example) attacker… ❑ Use a canary ❑ Address space layout randomization (ASLR) ❑ …without access to ❑ Use safe languages (Java, C#) ❑ Use safer C functions source code! o For unsafe functions, safer versions exist o For example, strncpy instead of strcpy Part 4 ⎯ Software 29 Part 4 ⎯ Software 30 Stack Smashing Defenses Microsoft’s Canary low → ❑ Microsoft added buffer security check : ❑ Canary : feature to C++ with /GS compiler flag o Run-time stack check o Based on canary (or “security cookie”) o Push canary onto stack Q: What to do when canary dies? A: Check for user-supplied “handler” o Canary value: buffer ❑ Handler shown to be subject to attack ▪ Constant 0x000aff0d overflowcanary ← o Claimed that attacker can specify handler code ▪ Or, may depends on ret overflowret o If so, formerly “safe” buffer overflows become a exploitable when /GS is used! high → b Part 4 ⎯ Software 31 Part 4 ⎯ Software 32 ASLR Buffer Overflow ❑ Address Space Layout Randomization ❑ A major security threat yesterday, today, o Randomize place where code loaded in memory and tomorrow ❑ Makes most buffer overflow attacks ❑ The good news? probabilistic o It is possible to reduce overflow attacks (safe ❑ Windows Vista uses 256 random layouts languages, NX bit, ASLR, education, etc.) o So about 1/256 chance buffer overflow works ❑ The bad news? ❑ Similar thing in Mac OS X and other OSs o Buffer overflows will exist for a long time ❑ Attacks against Microsoft’s ASLR do exist o Why? Legacy code, bad development practices, o Possible to “de-randomize” clever attacks, etc. Part 4 ⎯ Software 33 Part 4 ⎯ Software 34 Input Validation Incomplete Mediation ❑ Consider: strcpy(buffer, argv[1]) ❑ A buffer overflow occurs if len(buffer) < len(argv[1]) ❑ Software must validate the input by checking the length of argv[1] ❑ Failure to do so is an example of a more general problem: incomplete mediation Part 4 ⎯ Software 35