Outline Bernstein’s perspective CSci 5271 Introduction to Computer Security Announcements intermission Day 8: Defensive programming and design, part 2 Stephen McCamant Techniques for privilege separation University of Minnesota, Computer Science & Engineering 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 Note to early readers This is the section of the slides most likely to change Bernstein’s perspective in the final version If class has already happened, make sure you have Announcements intermission the latest slides for announcements Techniques for privilege separation In particular, the BCMTA vulnerability announcement is embargoed Last preview question BCECHO part 2, continued What is the return type of ❣❡t❝❤❛r✭✮ ? A. s✐❣♥❡❞ ❝❤❛r Modifying a system file B. ✐♥t ♥ 0-free shellcoding C. ✉♥s✐❣♥❡❞ ❝❤❛r Shellcode in an environment variable D. ❝❤❛r E. ❢❧♦❛t Outline Restricted languages Bernstein’s perspective Main application: code provided by untrusted parties Packet filters in the kernel Announcements intermission JavaScript in web browsers Also Java, Flash ActionScript, etc. Techniques for privilege separation
SFI Separate processes Software-based Fault Isolation OS (and hardware) isolate one process from another Instruction-level rewriting like (but predates) CFI Pay overhead for creation and communication Limit memory stores and sometimes loads System call interface allows many possibilities for Can’t jump out except to designated points mischief E.g., Google Native Client System-call interposition Interposition challenges Argument values can change in memory (TOCTTOU) Trusted process examines syscalls made by untrusted OS objects can change (TOCTTOU) Implement via ♣tr❛❝❡ (like strace, gdb) or via kernel How to get canonical object identifiers? change Interposer must accurately model kernel behavior Easy policy: deny Details: Garfinkel (NDSS’03) Separate users ❝❤r♦♦t Reuse OS facilities for access control Unix system call to change root directory Unit of trust: program or application Restrict/virtualize file system access Older example: qmail Only available to root Newer example: Android Does not isolate other namespaces Limitation: lots of things available to any user OS-enabled containers (System) virtual machines Presents hardware-like interface to an untrusted One kernel, but virtualizes all namespaces kernel FreeBSD jails, Linux LXC, Solaris zones, etc. Strong isolation, full administrative complexity Quite robust, but the full, fixed, kernel is in the TCB I/O interface looks like a network, etc.
Virtual machine designs Virtual machine technologies (Type 1) hypervisor: ‘superkernel’ underneath VMs Hardware based: fastest, now common Partial translation: e.g., original VMware Hosted: regular OS underneath VMs Paravirtualizaion: modify kernels in VMs for ease of Full emulation: e.g. QEMU proper virtualization Slowest, but can be a different CPU architecture 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 and Linux Basic (e.g., classic Unix) access control sandboxing techniques Blocked 70% of historic vulnerabilities, not all new ones ❤tt♣✿✴✴s❡❝❧❛❜✳st❛♥❢♦r❞✳❡❞✉✴✇❡❜s❡❝✴❝❤r♦♠✐✉♠✴
Recommend
More recommend
