Goals for Today CS 194 1 CS 161 Computer Security Next 3 lectures are about software security Can have perfect design specification algos but still have implementation vulnerabilities Lecture 13 Examine common implementation flaws Many security critical apps use C and C has peculiar pitfalls Software security Common implementation flaws Principles Implementation flaws can occur with improper use of language libraries OS or app logic Principles for building secure systems October 16 2006 Trusted computing base TCB Three Cryptographic principles 13 other security principles Prof Anthony D Joseph http cs161 org 10 16 06 Joseph CS161 UCB Fall 2006 Buffer Overrun Vulnerabilities Lec 13 2 Simple Example Most common class of implementation flaw C is basically a portable assembler char buf 80 void vulnerable gets buf Programmer exposed to bare machine No bounds checking for array or pointer accesses gets reads all input bytes available on stdin and stores them into buf What if input has more than 80 bytes Buffer overrun or buffer overflow vulnerabilities gets writes past end of buf overwriting some other part of memory This is a bug Out of bounds memory accesses used to corrupt program s intended behavior Results 10 16 06 Joseph CS161 UCB Fall 2006 Lec 13 3 10 16 06 Modified Example Function pointer fnptr invoked elsewhere What can attacker do Can overwrite fnptr with any address redirecting program execution Crafty attacker authenticated stored immediately after buf Attacker writes data after end of buf Input contains malicious machine instructions followed by pointer to overwrite fnptr When fnptr is next invoked flow of control re directed to malicious code Attacker supplies 81 bytes 81st set non zero Joseph CS161 UCB Fall 2006 Lec 13 4 More Serious Exploit Example A login routine sets authenticated flag only if user proves knowledge of password What s the risk 10 16 06 Joseph CS161 UCB Fall 2006 char buf 80 int fnptr char buf 80 int authenticated 0 void vulnerable gets buf Makes authenticated flag true Attacker gains access security breach Program crash core dump Much worse consequences possible This is a malicious code injection attack Lec 13 5 10 16 06 Page 1 Joseph CS161 UCB Fall 2006 Lec 13 6 Buffer Overrun Exploits Buffer Exploit History Demonstrate how adversaries might be able to use a buffer overrun bug to seize control How likely are the conditions required to exploit buffer overruns This is very bad Actually fairly rare Consider web server receives requests from clients and processes them But first Internet worm Morris worm spread using several attacks 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 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 System has been 0wned Buffer overrun vulnerabilities and malicious code injection attacks are primary favorite method used by worm writers 10 16 06 Joseph CS161 UCB Fall 2006 Lec 13 7 10 16 06 C Program Memory Layout Instruction pointer IP reg points to next machine instruction to execute Procedure call instruction Grows shrinks as objects allocated freed Pushes current IP onto stack return addr Jumps to beginning of function being called Stack local variable storage Grows shrinks with function calls returns heap 0x00 0 Compiler inserts prologue into each function stack Pushes current SP value of SP onto stack Allocates stack space for local variables by decrementing SP by appropriate amount 0xFF F 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 memory 10 16 06 Joseph CS161 UCB Fall 2006 Function return Old SP and return address retrieved from stack and stack frame popped from stack Execution continues from return address Lec 13 9 10 16 06 Stack Smashing Attack ret addr caller s stack frame 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 Given too long input saved SP and return addr will be overwritten This is the stack smashing attack 10 16 06 Joseph CS161 UCB Fall 2006 Lec 13 10 First attacker stashes malicious code sequence somewhere in program s address space use previous techniques Next attacker provides carefully chosen 88 byte sequence When vulnerable is called stack frame is pushed onto stack saved SP Joseph CS161 UCB Fall 2006 Stack Smashing Attack void vulnerable char buf 80 gets buf buf Lec 13 8 C Program Execution Text region program s executable code Heap dynamically allocated data text region Joseph CS161 UCB Fall 2006 Smashing the Stack for Fun and Profit written by Aleph One in November 1996 Lec 13 11 10 16 06 Page 2 Joseph CS161 UCB Fall 2006 Lec 13 12 Buffer Overrun Summary Buffer Overrun Summary Techniques for when Historically many security researchers have underestimated opportunities for obscure and sophisticated attacks 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 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 Exploiting buffer overruns appears mysterious complex or incredibly hard to exploit Buffer overruns are bad stuff you don t want them in your programs Reality it is none of the above Worms exploit these bugs all the time Code Red II compromised 250K machines by exploiting IIS buffer overrun 10 16 06 Joseph CS161 UCB Fall 2006 Lec 13 13 10 16 06 Format String Vulnerabilities Attack Examples Use string x x to see the first two words of stack memory What does this string x x s do Prints first two words of stack memory Treats next stack memory word as memory addr and prints everything until first 0 Do you see the bug Last line should be printf s buf If buf contains chars printf will look for non existent args and may crash or coredump trying to chase missing pointers Where does that last word of stack memory come from Somewhere in printf s stack frame or given enough x
View Full Document
Unlocking...