Outline More secure design principles Software engineering for - PDF document

Outline More secure design principles Software engineering for security CSci 5271 Introduction to Computer Security Secure use of the OS Defensive programming and design, cont’d Announcements intermission Stephen McCamant Bernstein’s perspective University of Minnesota, Computer Science & Engineering Techniques for privilege separation Back to an old preview question Separate the control plane Keep metadata and code separate from untrusted Asked before: what’s the type of the return value of data ❣❡t❝❤❛r ? Bad: format string vulnerability Why? Bad: old telephone systems Defense in depth Canonicalize names Use unique representations of objects Multiple levels of protection can be better than one E.g. in paths, remove ✳ , ✳✳ , extra slashes, symlinks Especially if none is perfect E.g., use IP address instead of DNS name But, many weak security mechanisms don’t add up Fail-safe / fail-stop Outline More secure design principles Software engineering for security If something goes wrong, behave in a way that’s safe Secure use of the OS Often better to stop execution than continue in corrupted state Announcements intermission E.g., better segfault than code injection Bernstein’s perspective Techniques for privilege separation

Modularity Minimize interfaces Divide software into pieces with well-defined Hallmark of good modularity: clean interface functionality Particularly difficult: Isolate security-critical code Safely implementing an interface for malicious users Minimize TCB, facilitate privilege separation Safely using an interface with a malicious implementation Improve auditability Appropriate paranoia Invariant A fact about the state of a program that should Many security problems come down to missing always be maintained checks Assumed in one place to guarantee in another But, it isn’t possible to check everything continuously Compare: proof by induction How do you know when to check what? Pre- and postconditions Dividing responsibility Invariants before and after execution of a function Program must ensure nothing unsafe happens Precondition: should be true before call Pre- and postconditions help divide that Postcondition: should be true after return responsibility without gaps When to check Sometimes you can’t check At least once before any unsafe operation If the check is fast Check that ♣ points to a null-terminated string If you know what to do when the check fails Check that ❢♣ is a valid function pointer If you don’t trust Check that ① was not chosen by an attacker your caller to obey a precondition your callee to satisfy a postcondition yourself to maintain an invariant

Error handling Error codes Every error must be handled Commonly, return value indicates error if any I.e, program must take an appropriate response action Bad: may overlap with regular result Errors can indicate bugs, precondition violations, or Bad: goes away if ignored situations in the environment Exceptions Testing and security “Testing shows the presence, not the absence of Separate from data, triggers jump to handler bugs” – Dijkstra Good: avoid need for manual copying, not dropped Easy versions of some bugs can be found by May support: automatic cleanup ( ❢✐♥❛❧❧② ) targeted tests: Buffer overflows: long strings Bad: non-local control flow can be surprising Integer overflows: large numbers Format string vulnerabilities: ✪① Fuzz testing Modern fuzz testing Mutation fuzzing: small random changes to a benign seed input Random testing can also sometimes reveal bugs Complex benign inputs help cover interesting functionality Original ‘fuzz’ (Miller): ♣r♦❣r❛♠ ❁✴❞❡✈✴✉r❛♥❞♦♠ Grammar-based fuzzing: randomly select valid inputs Coverage-driven fuzzing: build off of tests that cause Even this was surprisingly effective new parts of the program to execute Automatically learns what inputs are “interesting” Pioneered in the open-source AFL tool Outline Avoid special privileges More secure design principles Require users to have appropriate permissions Software engineering for security Rather than putting trust in programs Secure use of the OS Anti-pattern 1: setuid/setgid program Announcements intermission Anti-pattern 2: privileged daemon Bernstein’s perspective But, sometimes unavoidable (e.g., email) Techniques for privilege separation

One slide on setuid/setgid Don’t use shells or Tcl Unix users and process have a user id number (UID) . . . in security-sensitive applications as well as one or more group IDs String interpretation and re-parsing are very hard to Normally, process has the IDs of the use who starts do safely it Eternal Unix code bug: path names with spaces A setuid program instead takes the UID of the program binary Prefer file descriptors Prefer absolute paths Maintain references to files by keeping them open Use full paths (starting with ✴ ) for programs and files and using file descriptors, rather than by name ✩P❆❚❍ under local user control References same contents despite file system Initial working directory under local user control changes But FD-like, so can be used in place of ♦♣❡♥❛t if missing Use ♦♣❡♥❛t , etc., variants to use FD instead of directory paths Prefer fully trusted paths Don’t separate check from use Avoid pattern of e.g., ❛❝❝❡ss then ♦♣❡♥ Each directory component in a path must be write Instead, just handle failure of open protected You have to do this anyway Read-only file in read-only directory can be changed Multiple references allow races if a parent directory is modified And ❛❝❝❡ss also has a history of bugs Be careful with temporary files Give up privileges Using appropriate combinations of s❡t✯✐❞ functions Create files exclusively with tight permissions and Alas, details differ between Unix variants never reopen them Best: give up permanently See detailed recommendations in Wheeler Not quite good enough: reopen and check matching Second best: give up temporarily device and inode Detailed recommendations: Setuid Demystified Fails with sufficiently patient attack (USENIX’02)

Whitelist environment variables Outline More secure design principles Can change the behavior of called program in Software engineering for security unexpected ways Secure use of the OS Decide which ones are necessary Announcements intermission As few as possible Save these, remove any others Bernstein’s perspective Techniques for privilege separation Last preview question BCMTA vulnerability found! What is the return type of ❣❡t❝❤❛r✭✮ ? A user can process incoming messages with a A. s✐❣♥❡❞ ❝❤❛r command using ✳❢♦r✇❛r❞ B. ✐♥t BCMTA should drop privileges when running this C. ✉♥s✐❣♥❡❞ ❝❤❛r command D. ❝❤❛r Because of a logic error, did so only the first time E. ❢❧♦❛t BCECHO part 2, continued Outline More secure design principles Software engineering for security Modifying a system file Secure use of the OS ♥ 0-free shellcoding Announcements intermission Shellcode in an environment variable Bernstein’s perspective Techniques for privilege separation Historical background Distinctive qmail features Traditional Unix MTA: Sendmail (BSD) Monolithic setuid root program Single, security-oriented developer Designed for a more trusting era Architecture with separate programs and UIDs In mid-90s, bugs seemed endless Replacements for standard libraries Spurred development of new, security-oriented replacements Deliveries into directories rather than large files Bernstein’s qmail Venema et al.’s Postfix

Ineffective privilege separation Effective privilege separation Example: prevent Netscape DNS helper from Transformations with constrained I/O accessing local file system General argument: worst adversary can do is control Before: bug in DNS code 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 $500, later $1000 offered for security bug Originally had terms that prohibited modified redistribution Never paid out Now true public domain Issues proposed: Latest release from Bernstein: 1998; netqmail: 2007 Memory exhaustion DoS Overflow of signed integer indexes Does not have large market share Defensiveness does not encourage more All MTAs, even Sendmail, are more secure now submissions Outline Restricted languages More secure design principles Software engineering for security Main application: code provided by untrusted parties Secure use of the OS Packet filters in the kernel JavaScript in web browsers Announcements intermission Also Java, Flash ActionScript, etc. Bernstein’s perspective Techniques for privilege separation