Page 1CS 194-1 (CS 161) Computer SecurityLecture 13Software security; Common implementation flaws; PrinciplesOctober 16, 2006Prof. Anthony D. Josephhttp://cs161.org/Lec 13. 210/16/06 Joseph CS161 ©UCB Fall 2006Goals for Today• Next 3 lectures are about software security– Can have perfect design, specification, algos, but still have implementation vulnerabilities!• Examine common implementation flaws– Many security-critical apps use C, and C has peculiar pitfalls • Implementation flaws can occur with improper use of language, libraries, OS, or app logic• Principles for building secure systems– Trusted computing base (TCB)– Three Cryptographic principles– 13 other security principlesLec 13. 310/16/06 Joseph CS161 ©UCB Fall 2006Buffer Overrun Vulnerabilities• Most common class of implementation flaw• C is basically a portable assembler– Programmer exposed to bare machine– No bounds-checking for array or pointer accesses• Buffer overrun (or buffer overflow) vulnerabilities– Out-of-bounds memory accesses used to corrupt program’s intended behaviorLec 13. 410/16/06 Joseph CS161 ©UCB Fall 2006Simple Example• char buf[80];void vulnerable() {gets(buf);}• gets() reads all input bytes available on stdin, and stores them into buf[]• What if input has more than 80 bytes?– gets() writes past end of buf, overwriting some other part of memory– This is a bug!• Results?– Program crash/core-dump?– Much worse consequences possible…Lec 13. 510/16/06 Joseph CS161 ©UCB Fall 2006Modified Example• char buf[80];int authenticated = 0; void vulnerable() {gets(buf);}• A login routine sets authenticated flag only if user proves knowledge of password• What’s the risk?–authenticated stored immediately after buf– Attacker “writes” data after end of buf• Attacker supplies 81 bytes (81stset non-zero)– Makes authenticated flag true!– Attacker gains access: security breach!Lec 13. 610/16/06 Joseph CS161 ©UCB Fall 2006More Serious Exploit Example• char buf[80];int (*fnptr)();...• Function pointer fnptr invoked elsewhere• What can attacker do?– Can overwrite fnptr with any address, redirecting program execution! • Crafty attacker:– Input contains malicious machine instructions, followed by pointer to overwrite fnptr– When fnptr is next invoked, flow of control re-directed to malicious code• This is a malicious code injection attackPage 2Lec 13. 710/16/06 Joseph CS161 ©UCB Fall 2006Buffer Overrun Exploits• Demonstrate how adversaries might be able to use a buffer overrun bug to seize control– This is very bad!• Consider: web server receives requests from clients and processes them– With a buffer overrun in the code, malicious client could seize control of server process– If server is running as root, attacker gains root access and can leave a backdoor» System has been “0wned”• Buffer overrun vulnerabilities and malicious code injection attacks are primary/favorite method used by worm writers Lec 13. 810/16/06 Joseph CS161 ©UCB Fall 2006Buffer Exploit History• How likely are the conditions required to exploit buffer overruns?– Actually fairly rare…• But, first Internet worm (Morris worm) spread using several attacks– One used buffer overrun to overwrite authenticated flag in in.fingerd (network finger daemon)• Attackers have discovered much more effective methods of malicious code injection…Lec 13. 910/16/06 Joseph CS161 ©UCB Fall 2006C Program Memory Layout• Text region (program’s executable code)• Heap, (dynamically allocated data)– Grows/shrinks as objects allocated/freed• Stack (local variable storage)– Grows/shrinks with function calls/returns• Function call pushes new stack frame on stack– Frame includes space for function’s local vars– Intel (x86) machines stack grows “down”– Stack pointer (SP) reg points to current frame– Stack extends from SP to the end of memory0xFF…F0x00…0heap … stacktext regionLec 13. 1010/16/06 Joseph CS161 ©UCB Fall 2006C Program Execution• Instruction pointer (IP) reg points to next machine instruction to execute• Procedure call instruction:– Pushes current IP onto stack (return addr)– Jumps to beginning of function being called• Compiler inserts prologue into each function– Pushes current SP value of SP onto stack– Allocates stack space for local variables by decrementing SP by appropriate amount• Function return:– Old SP and return address retrieved from stack, and stack frame popped from stack– Execution continues from return addressLec 13. 1110/16/06 Joseph CS161 ©UCB Fall 2006Stack Smashing Attack• void vulnerable() {char buf[80];gets(buf);}• When vulnerable() is called, stack frame is pushed onto stack• Given “too-long” input, saved SP and return addr will be overwritten• This is the stack smashing attack!…caller’s stack framebuf saved SP ret addrLec 13. 1210/16/06 Joseph CS161 ©UCB Fall 2006Stack Smashing Attack• First, attacker stashes malicious code sequence somewhere in program’s address space (use previous techniques)• Next, attacker provides carefully-chosen 88-byte sequence– Last four bytes chosen to hold code’s address overwrite saved return address• When vulnerable() returns, CPU loads attacker’s return addr – handing control over to attacker's malicious code• Stack smashing exploit reference:– “Smashing the Stack for Fun and Profit,”written by Aleph One in November 1996Page 3Lec 13. 1310/16/06 Joseph CS161 ©UCB Fall 2006Buffer Overrun Summary• Techniques for when:– Malicious code gets stored at unknown location– Buffer stored on the heap instead of on stack– Can only overflow buffer by one byte– Characters written to buffer are limited (e.g., only uppercase characters)– …• Exploiting buffer overruns appears mysterious, complex, or incredibly hard to exploit – Reality – it is none of the above!• Worms exploit these bugs all the time– Code Red II compromised 250K machines by exploiting IIS buffer overrunLec 13. 1410/16/06 Joseph CS161 ©UCB Fall 2006Buffer Overrun Summary• Historically, many security researchers have underestimated opportunities for obscure and sophisticated attacks– Very easy mistake to make…• Lesson learned:– If your program has a buffer overrun bug, assume that the bug is exploitable and an attacker can take control of program• Buffer overruns are bad stuff – you don’t want them in your
View Full Document
Unlocking...