Outline CSci 5271 Bernsteins perspective Introduction to Computer - PDF document

Outline CSci 5271 Bernstein’s perspective Introduction to Computer Security Day 8: Defensive programming and design, Announcements intermission part 2 Stephen McCamant Techniques for privilege separation University of Minnesota, Computer Science & Engineering 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 Note to early readers Bernstein’s perspective This is the section of the slides most likely to change in the final version Announcements intermission If class has already happened, make sure you have the latest slides for Techniques for privilege separation announcements

Outline Restricted languages Bernstein’s perspective Main application: code provided by untrusted parties Announcements intermission Packet filters in the kernel JavaScript in web browsers Techniques for privilege separation Also Java, Flash ActionScript, etc. SFI Separate processes Software-based Fault Isolation Instruction-level rewriting like (but OS (and hardware) isolate one process from another predates) CFI Pay overhead for creation and Limit memory stores and sometimes 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 OS-enabled containers (System) virtual machines One kernel, but virtualizes all Presents hardware-like interface to an namespaces untrusted kernel FreeBSD jails, Linux LXC, Solaris zones, Strong isolation, full administrative etc. complexity Quite robust, but the full, fixed, kernel is I/O interface looks like a network, etc. in the TCB Virtual machine designs Virtual machine technologies (Type 1) hypervisor: ‘superkernel’ Hardware based: fastest, now common underneath VMs Partial translation: e.g., original VMware Hosted: regular OS underneath VMs Full emulation: e.g. QEMU proper Paravirtualizaion: modify kernels in VMs Slowest, but can be a different CPU architecture for ease of virtualization

Modern example: Chrom(ium) Next time Separates “browser kernel” from less-trusted “rendering engine” Pragmatic, keeps high-risk components together Protection and isolation Experimented with various Windows Basic (e.g., classic Unix) access control and Linux sandboxing techniques Blocked 70% of historic vulnerabilities, not all new ones ❤tt♣✿✴✴s❡❝❧❛❜✳st❛♥❢♦r❞✳❡❞✉✴✇❡❜s❡❝✴ ❝❤r♦♠✐✉♠✴