Outline Saltzer & Schroeder’s principles (cont’d) CSci 5271 More secure design principles Introduction to Computer Security Software engineering for security Defensive programming 2 (combined lecture) Announcements intermission Stephen McCamant Bernstein’s perspective University of Minnesota, Computer Science & Engineering Techniques for privilege separation Least common mechanism Psychological acceptability Minimize the code that all users must A system must be easy to use, if users depend on for security are to apply it correctly Related term: minimize the Trusted Make the system’s model similar to the Computing Base (TCB) user’s mental model to minimize E.g.: prefer library to system call; mistakes microkernel OS Sometimes: work factor Sometimes: compromise recording Cost of circumvention should match Recording a security failure can be attacker and resource protected almost as good as preventing it E.g., length of password But, few things in software can’t be But, many attacks are easy when you erased by r♦♦t know the bug
Outline Pop quiz Saltzer & Schroeder’s principles (cont’d) More secure design principles What’s the type of the return value of Software engineering for security ❣❡t❝❤❛r ? Announcements intermission Why? Bernstein’s perspective Techniques for privilege separation Separate the control plane Defense in depth Multiple levels of protection can be Keep metadata and code separate better than one from untrusted data Especially if none is perfect Bad: format string vulnerability But, many weak security mechanisms Bad: old telephone systems don’t add up Canonicalize names Fail-safe / fail-stop If something goes wrong, behave in a Use unique representations of objects way that’s safe E.g. in paths, remove ✳ , ✳✳ , extra Often better to stop execution than slashes, symlinks continue in corrupted state E.g., use IP address instead of DNS name E.g., better segfault than code injection
Outline Modularity Saltzer & Schroeder’s principles (cont’d) Divide software into pieces with More secure design principles well-defined functionality Software engineering for security Isolate security-critical code Announcements intermission Minimize TCB, facilitate privilege separation Bernstein’s perspective Improve auditability Techniques for privilege separation Minimize interfaces Appropriate paranoia Hallmark of good modularity: clean Many security problems come down to interface missing checks Particularly difficult: But, it isn’t possible to check everything Safely implementing an interface for continuously malicious users Safely using an interface with a malicious How do you know when to check what? implementation Invariant Pre- and postconditions A fact about the state of a program Invariants before and after execution of that should always be maintained a function Assumed in one place to guarantee in Precondition: should be true before call another Postcondition: should be true after Compare: proof by induction return
Dividing responsibility When to check At least once before any unsafe operation Program must ensure nothing unsafe If the check is fast happens If you know what to do when the check Pre- and postconditions help divide that fails responsibility without gaps If you don’t trust your caller to obey a precondition your callee to satisfy a postcondition yourself to maintain an invariant Sometimes you can’t check Error handling Every error must be handled Check that ♣ points to a null-terminated I.e, program must take an appropriate string response action Check that ❢♣ is a valid function pointer Errors can indicate bugs, precondition Check that ① was not chosen by an violations, or situations in the attacker environment Error codes Exceptions Separate from data, triggers jump to handler Commonly, return value indicates error Good: avoid need for manual copying, if any not dropped Bad: may overlap with regular result May support: automatic cleanup Bad: goes away if ignored ( ❢✐♥❛❧❧② ) Bad: non-local control flow can be surprising
Testing and security Fuzz testing “Testing shows the presence, not the Random testing can also sometimes absence of bugs” – Dijkstra reveal bugs Easy versions of some bugs can be Original ‘fuzz’ (Miller): ♣r♦❣r❛♠ found by targeted tests: ❁✴❞❡✈✴✉r❛♥❞♦♠ Buffer overflows: long strings Modern: small random changes to a Integer overflows: large numbers benign input Format string vulnerabilities: ✪① Outline BCMTA pre-release posted Saltzer & Schroeder’s principles (cont’d) Version 0.9 of source code includes most features and many vulnerabilities More secure design principles This version includes a pretty obvious Software engineering for security back-door which will be the first Announcements intermission problem to be fixed Can’t properly test without VM, but you Bernstein’s perspective can start reading the code Techniques for privilege separation Reminder: register groups for a VM What is BCMTA? HA1 types of vulnerabilities A badly coded mail-transfer agent, similar to sendmail or qmail OS interaction/logic errors Can run from the command-line Can receive messages over the network Memory safety errors (SMTP on standard input) E.g., exploit with control-flow hijacking Needs to run as root to deliver to any Attacks may require crafted text files user’s mailbox and chosen program inputs Attacker’s goal: use root privilege to take over machine Specifically: root shell
Other upcoming assignments Outline Saltzer & Schroeder’s principles (cont’d) Project progress reports: due next More secure design principles Monday 2/25 Software engineering for security Remember, these are individual Announcements intermission Exercise set 2: due week from Wednesday, 2/27 Bernstein’s perspective Techniques for privilege separation Historical background Distinctive qmail features Traditional Unix MTA: Sendmail (BSD) Single, security-oriented developer Monolithic setuid root program Architecture with separate programs Designed for a more trusting era and UIDs In mid-90s, bugs seemed endless Spurred development of new, Replacements for standard libraries security-oriented replacements Deliveries into directories rather than Bernstein’s qmail large files Venema et al.’s Postfix Ineffective privilege separation Effective privilege separation Example: prevent Netscape DNS helper Transformations with constrained I/O from accessing local file system General argument: worst adversary can Before: bug in DNS code do is control output ✦ read user’s private files Which is just the benign functionality After: bug in DNS code MTA header parsing (Sendmail bug) ✦ inject bogus DNS results ❥♣❡❣t♦♣♥♠ inside ①❧♦❛❞✐♠❛❣❡ ✦ man-in-the-middle attack ✦ read user’s private web data
Eliminating bugs Eliminating code Identify common functions Enforce explicit data flow Automatically handle errors Simplify integer semantics Reuse network tools Avoid parsing Reuse access controls Generalize from errors to inputs Reuse the filesystem The “qmail security guarantee” qmail today Originally had terms that prohibited $500, later $1000 offered for security modified redistribution bug Now true public domain Never paid out Latest release from Bernstein: 1998; Issues proposed: netqmail: 2007 Memory exhaustion DoS Does not have large market share Overflow of signed integer indexes All MTAs, even Sendmail, are more Defensiveness does not encourage secure now more submissions Outline Restricted languages Saltzer & Schroeder’s principles (cont’d) More secure design principles Main application: code provided by untrusted parties Software engineering for security Packet filters in the kernel Announcements intermission JavaScript in web browsers Bernstein’s perspective Also Java, Flash ActionScript, etc. Techniques for privilege separation
SFI Separate processes Software-based Fault Isolation OS (and hardware) isolate one process Instruction-level rewriting like (but predates) CFI from another Limit memory stores and sometimes Pay overhead for creation and communication loads System call interface allows many Can’t jump out except to designated possibilities for mischief points E.g., Google Native Client System-call interposition Interposition challenges Argument values can change in Trusted process examines syscalls memory (TOCTTOU) made by untrusted OS objects can change (TOCTTOU) Implement via ♣tr❛❝❡ (like strace, gdb) How to get canonical object identifiers? or via kernel change Interposer must accurately model Easy policy: deny kernel behavior Details: Garfinkel (NDSS’03) Separate users ❝❤r♦♦t Reuse OS facilities for access control Unix system call to change root Unit of trust: program or application directory Older example: qmail Restrict/virtualize file system access Newer example: Android Only available to root Limitation: lots of things available to Does not isolate other namespaces any user
Recommend
More recommend
