RAKSHA A Flexible Information Flow Architecture for Software Security Michael Dalton Hari Kannan Christos Kozyrakis Computer Systems Laboratory Stanford University

@ 2006, Michael Dalton 2 Motivation  Software security is in a crisis Far-reaching financial & social implications  Worms now mixing different kinds of attacks No longer just simple buffer overflows  High-level semantic vulnerabilities now most common threats SQL Injection, Cross Site Scripting, Directory Traversal, etc Easy to exploit; often architecture & OS independent  Need a new approach that is Robust, End-to-end, Practical, Flexible, Fast

@ 2006, Michael Dalton 3 Dynamic Information Flow Tracking  DIFT tags (taints) data from untrusted sources Each byte or word of memory, register has a taint bit  Taint is propagated across instructions If any source operand is tainted, destination becomes tainted  Trap to OS if tainted data used unsafely Tainted pointer dereference Tainted jump address Tainted code  Can prevent memory corruption on unmodified binaries

@ 2006, Michael Dalton 4 Limitations of Current DIFT Systems  Software-based DIFT is slow and impractical >3x overhead, source-code access, does not work with threads …  Hardware-based DIFT uses one, fixed security policy Can only solve one problem (e.g., memory corruption)  unsafe  High-level attacks cannot be addressed Cannot adapt to code that violates policy assumptions  impactical  E.g. glib uses alternate bounds checking instructions Vulnerable to attacks that exploit inflexibility of policies  Hardware security exceptions generate OS traps Cannot protect OS  not end-to-end Cannot combined HW and SW to cover difficult cases  inflexible  On a trap, just terminate the program…

@ 2006, Michael Dalton 5 RAKSHA Overview  Raksha follows the general DIFT model All state is extended by a 4-bit tag (registers & memory) Operations propagate tags from sources to destinations Operations check tags to identify security traps  New features Software-controlled check & propagate policies  flexibility  Specify policy using check, propagate registers  Fine-grain software control to avoid common pitfalls  Flexibility allows us to catch wide range of bugs Up to 4 concurrently active policies  robustness  One policy per tag bit  Provide comprehensive protection against many bugs Low-overhead, user-level, security traps  end-to-end, flexibility  Can extend with software; can check operating system

@ 2006, Michael Dalton 6 Policy Specification  One check & propagate register per active security policy  Policies specified at granularity of primitive operation Int/FP Arithmetic, Move, Logical, Comparison, Execute  Instructions are decoded into ≥1 primitive operations Apply rules specified by check/prop regs to each operation Addresses basic pitfalls of previous designs  Additional support for custom rules

@ 2006, Michael Dalton 7 Low Overhead Security Traps  A tag checks invoke pre-registered handler Handler in same address space as code under inspection Handler invocation triggers a special “trusted mode”  A security policy used to protect handler code & data Code & data are tainted Policy does not allow access outside of trusted mode  Benefits Can check security of (most of the) OS  Reduce the amount of code you really trust Coupling HW and SW security analysis is practical  Low performance overhead

@ 2006, Michael Dalton 8 Raksha-based LEON3

@ 2006, Michael Dalton 9 Raksha Implementation Summary  Full-system prototype based on LEON 3 Open source processor from Gaisler Research SPARC V8 compliant  Synthesized on Virtex 2 FPGA board ParameterSpecification Pipeline depth7 stages Instruction Cache8KB Data Cache32KB Clock frequency20 Mhz Block RAM utilization22% 4 input LUT utilization42% Total increase in gates due to tags7.17%

@ 2006, Michael Dalton 10 Raksha Software Infrastructure  Goal: run real-world software stack Running a full-featured Linux 2.6 on Raksha hardware  Custom distribution booting over NFS Full GNU toolchain + glibc  Over 120 packages total  Support enterprise software SSH Postgresql wu-ftpd Apache …

@ 2006, Michael Dalton 11 Security Results  Detected and prevented wide range of security attacks Includes high-level semantic attacks All analyses run on unmodified application binaries ProgramAttackDetected Vulnerability gzipDirectory TraversalOpen tainted dir OpenSSHCommand Injectionexecve tainted file ProFPDSQL Injectiontainted SQL query htdigCross-Site Scripting Tainted output with tag tracerouteDouble freeTainted data ptr polymorphBuffer OverflowTainted code ptr Wu-FTPDFormat StringTainted format string in vfprintf

@ 2006, Michael Dalton 12 Performance Results  Overhead is analysis-dependent Proportional to exceptions frequency and handler duration Many analyses are very cheap  Most high-level analyses invoked infrequently Buffer overflow protection can be most expensive  If software is used to correctly filter false-positives/negatives  Buffer overflow overhead ProgramExceptionOS trap gcc1.01x1.04x crafty1.01x1.02x gzip1.31x3.60x bzip22.99x18.80x vortex1.34x3.41x

@ 2006, Michael Dalton 13 Conclusions  Security trends require flexible solutions High-level vulnerabilities now most common bug  Previous information flow work inflexible Fixed policies that only address one problem (buffer overflow)  Raksha: a flexible DIFT architecture for security Software controlled policies, multiple policies, software extensible  Full-system Raksha prototype using FPGA board Modified Leon3 + Linux 2.6 Protected unmodified binaries from real-world vulnerabilities Simultaneously protect against high-level web attacks, semantic vulnerabilities, and low-level buffer overflows

@ 2006, Michael Dalton 14 Future Work  Demonstrate OS protection  Whole system information flow Across processes & files Experiment with more flexible notion of trust and taintedness  Information flow OS Collaboration with HiStar group at Stanford  Beyond Security Debugging  Unlimited watchpoints, breakpoints, info flow in gdb DRAM error modeling Migrate dynamic analyses to unmodified binaries Fault Isolation Tag-aware VMs, interpreters