DOC PREVIEW
Berkeley COMPSCI 161 - Lecture Notes

This preview shows page 1-2-3 out of 10 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 10 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 10 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 10 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 10 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

Page 1CS 194-1 (CS 161) Computer SecurityLecture 15Software security(defensive programming)October 23, 2006Prof. Anthony D. Josephhttp://cs161.org/Lec 15. 210/23/06 Joseph CS161 ©UCB Fall 2006Review: Defensive Programming• Like defensive driving, but for code: – Avoid depending on others, so that if they do something unexpected, you won’t crash – survive unexpected behavior• 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• Defensive programming– Apply idea at every interface or security perimeter» So each module remains robust even if all others misbehave• General strategy– Assume attacker controls module’s inputs, make sure nothing terrible happensLec 15. 310/23/06 Joseph CS161 ©UCB Fall 2006Goals for Today• Defensive programming techniques to avoid security holes when writing code– Several good practices– Lots of overlap with software engineering and general software quality, but security places heavier demands• Isolation– Software techniques for keeping suspect programs from affecting other apps or the OS» Separate program modules» System call interposition» Virtual MachinesLec 15. 410/23/06 Joseph CS161 ©UCB Fall 2006Some General Advice• 1. Check for error conditions– Check rv’s, error paths, exception handling– Always safe to use fail-stop behavior• 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» Better to limit inputs to expected values (might cause some loss of functionality) than to liberally allow all (might permit unexpected security holes)Lec 15. 510/23/06 Joseph CS161 ©UCB Fall 2006What’s Wrong with this Code?• 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);• 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!Lec 15. 610/23/06 Joseph CS161 ©UCB Fall 2006Advice: 3. Whitelist, Don’t Blacklist• Common mistake:– 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 default-allow policy)– Can overlook some patterns of dangerous inputs• Instead, use whitelist of known-good types of inputs, and block anything else– Default-deny policy (much safer)Page 2Lec 15. 710/23/06 Joseph CS161 ©UCB Fall 2006Whitelisting Example• Check a username using a regular expression:– [a-z][a-z0-9]*– 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;}• Use with appropriate error-checking before using a user-supplied usernameLec 15. 810/23/06 Joseph CS161 ©UCB Fall 2006More Advice• 4. Don’t crash or enter infinite loops, Don’t corrupt memory– 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:» Attacker supplies inputs that lead to worst-case performance (hashtable with O(1) expected, but O(n) worst case lookup)Lec 15. 910/23/06 Joseph CS161 ©UCB Fall 2006More Advice• 5. Beware of integer overflow– Integer overflow often violates programmer’s mental model and leads to unexpected (undesired) behavior• 6. Check exception-safety of the code– 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 boundariesLec 15. 1010/23/06 Joseph CS161 ©UCB Fall 2006Famous Example: Ariane 5• Ariane 4 flight control sw written in Ada– Same software reused for more powerful Ariane 5• Ariane 5 blew up shortly after first launch– Cause: uncaught integer overflow exception caused software to terminate abruptly…• 16-bit reg: flight trajectory’s horizontal velocity– 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 millionLec 15. 1110/23/06 Joseph CS161 ©UCB Fall 2006Multiple Clients• Module M supports multiple clients– 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)– One client can’t disrupt another or corrupt M’s state– Thus, functional programming simplifies defensive programming taskLec 15. 1210/23/06 Joseph CS161 ©UCB Fall 2006Pre-Condition Choices• 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)?– 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• Don’t need to worry as much about internal helper functionsPage 3Lec 15. 1310/23/06 Joseph CS161 ©UCB Fall 2006Security Choices for 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


View Full Document

Berkeley COMPSCI 161 - Lecture Notes

Documents in this Course
Rootkits

Rootkits

11 pages

Load more
Download Lecture Notes
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Lecture Notes and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Lecture Notes 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?