Review Defensive Programming CS 194 1 CS 161 Computer Security Like defensive driving but for code Avoid depending on others so that if they do something unexpected you won t crash survive unexpected behavior Lecture 15 Software engineering focuses on functionality Given correct inputs code produces useful correct outputs Security cares about what happens when program is given invalid or unexpected inputs Shouldn t crash cause undesirable side effects or produce dangerous outputs for bad inputs Software security defensive programming Defensive programming Apply idea at every interface or security perimeter October 23 2006 So each module remains robust even if all others misbehave Prof Anthony D Joseph http cs161 org General strategy Assume attacker controls module s inputs make sure nothing terrible happens 10 23 06 Goals for Today Some General Advice Check rv s error paths exception handling Always safe to use fail stop behavior Several good practices Lots of overlap with software engineering and general software quality but security places heavier demands 2 Validate All Inputs Sanity check all inputs from rest of program Treat external inputs could be from adversary with particular caution Check that the input looks reasonable Be conservative Isolation Software techniques for keeping suspect programs from affecting other apps or the OS Separate program modules Better to limit inputs to expected values might cause some loss of functionality than to liberally allow all might permit unexpected security holes System call interposition Virtual Machines Joseph CS161 UCB Fall 2006 Lec 15 3 10 23 06 What s Wrong with this Code Lec 15 4 Common mistake char username getenv USER char buf malloc strlen username 6 sprintf buf mail s username FILE f popen buf r fprintf f Hi n fclose f Joseph CS161 UCB Fall 2006 Joseph CS161 UCB Fall 2006 Advice 3 Whitelist Don t Blacklist When validating input from an untrusted source trying to enumerate bad inputs and block them Don t do that Why Known as blacklisting analogous to defaultallow policy Can overlook some patterns of dangerous inputs Answer If attacker controls USER environment variable then could arrange for its value to be something like adj bin rm rf HOME popen passes its input to shell for execution and shell will execute command mail adj followed by bin rm rf HOME Solution validate that username looks reasonable If attacker can control other env vars e g PATH then could cause wrong mail command to be invoked have to validate whole environment 10 23 06 Lec 15 2 1 Check for error conditions Defensive programming techniques to avoid security holes when writing code 10 23 06 Joseph CS161 UCB Fall 2006 Instead use whitelist of known good types of inputs and block anything else Default deny policy much safer Lec 15 5 10 23 06 Page 1 Joseph CS161 UCB Fall 2006 Lec 15 6 Whitelisting Example More Advice Check a username using a regular expression 4 Don t crash or enter infinite loops Don t corrupt memory a z a z0 9 Regardless of received inputs NO abnormal termination infinite loops internal state corruption control flow hijacks Explicitly validate all inputs and avoid memory leaks Defend against DoS attacks char validate username char u char p if u u a u z die for p u 1 p p if p 0 p 9 p a p z die return u Attacker supplies inputs that lead to worstcase performance hashtable with O 1 expected but O n worst case lookup Use with appropriate error checking before using a user supplied username 10 23 06 Joseph CS161 UCB Fall 2006 Lec 15 7 10 23 06 More Advice Famous Example Ariane 5 Same software reused for more powerful Ariane 5 Integer overflow often violates programmer s mental model and leads to unexpected undesired behavior Ariane 5 blew up shortly after first launch Cause uncaught integer overflow exception caused software to terminate abruptly 6 Check exception safety of the code 16 bit reg flight trajectory s horizontal velocity Explicitly programmer thrown and implicitly platform thrown exceptions Verify that your code doesn t throw runtime exceptions null ptr deref div 0 Less restrictively check that all such exceptions are handled and will propagate across module boundaries Joseph CS161 UCB Fall 2006 Ariane 4 verified range of physically possible flight trajectories could not overflow variable so no need for exception handler Ariane 5 s rocket engine was more powerful causing larger horizontal velocity to be stored into register triggering overflow Losses of around 500 million Lec 15 9 10 23 06 Multiple Clients Lec 15 10 Use precondition and leave it to caller to ensure it is true Or explicitly check for ourselves that condition holds and abort if it doesn t How should we decide between these two strategies for externally invoked fcns Must defend itself against malicious clients Isolate malicious clients from each other M may in turn invoke other utility modules Same requirements apply Exception M computes a pure function no internal state or I O Use documented preconditions to express intended contract Use explicit checking for anything that could corrupt our internal state cause us to crash or disrupt other clients One client can t disrupt another or corrupt M s state Thus functional programming simplifies defensive programming task Joseph CS161 UCB Fall 2006 Joseph CS161 UCB Fall 2006 Pre Condition Choices Module M supports multiple clients 10 23 06 Lec 15 8 Ariane 4 flight control sw written in Ada 5 Beware of integer overflow 10 23 06 Joseph CS161 UCB Fall 2006 Don t need to worry as much about internal helper functions Lec 15 11 10 23 06 Page 2 Joseph CS161 UCB Fall 2006 Lec 15 12 Security Choices for Languages Dealing with Insecure Languages Pick tools that you know well Many security bugs caused by insufficient familiarity with obscure corner cases in language libraries or programming env Read and understand formal language spec Pick a prog platform designed for safety 50 of security holes in C code related to absence of bounds checking in C Choose strong type checking and automatic array ptr bounds checking memory mgmt and uninitialized variables Assembly language is a poor choice so easy to make devastating mistakes Can t always choose the language based on security Other considerations may dominate Or may be forced to maintain legacy code Need to be extra careful Avoid obscure corners of language If no automatic bounds checking consider inserting manual bounds checks Consider writing code so you can prove that out of bounds
View Full Document
Unlocking...