1. 1 RAKSHA: A FLEXIBLE ARCHITECTURE FOR SOFTWARE SECURITY Computer Systems Laboratory Stanford University Hari Kannan, Michael Dalton, Christos Kozyrakis August 2007

2. PRESENTATION OUTLINE  Motivation  Goals of a Security Technique  What is Dynamic Information Flow Tracking  Raksha Architecture  Security and Performance Evaluation  Summary  Questions 2

3. MOTIVATION  High-level semantic vulnerabilities are prevalent in web-based attacks  SQL injection – code inserted into entry field  Cross-Site Scripting (XSS)  Injected website sends malicious code to client  Real-World Examples:  Website database breach  The Wall Street Journal database in July 2014  Twitter worms 3 statement = "SELECT * FROM users WHERE name ='" + userName + "';" SELECT * FROM users WHERE name = ‘bob' OR '1'='1'; ‘bob’ OR '1'='1 userName: ERROR!

4. GOALS OF SECURITY TECHNIQUES Robust Flexible End-to- End Practical Fast 4 Few false positives or false negatives Adapt to cover evolving threats Cover all parts of the system Easy to implement Low overhead

5. WHAT IS DIFT? DIFT – Dynamic Information Flow Tracking  Associates a tag with every word of memory  Tag is used to mark tainted data from untrusted sources  Data produced from tainted data is also tainted  Check tag when data is used for potentially unsafe operations (ex. Code Execution)  Detects both low and high-level attacks 5 userName= X ‘bob’ X OR X ‘1’=‘1 TagData 'bob' OR '1'='1 userName: User input (untrusted) Tag Check SECURITY TRAP

6. RAKSHA ARCHITECTURE OVERVIEW  Hardware-supported DIFT  Tag checking in Pipeline  Key Features of Raksha:  4-bit Tags per Word  Programmable security policies  User-level Exception handling 6 User Program A User Program B OS Security Handler Hardware Tags & Checkers Tag Aware 32-bit Word Tag Memory Registers Cache lines One Tag per Policy

7. RAKSHA: TAG AND POLICY REGISTERS  4-bit tag for each word in registers, cache lines, and memory  Allow up to four different policies  Each policy (tag bit) comes with two configuration registers:  Tag Check Register (TCR) - Specify what checks to enable for different instructions  Tag Propagation Register (TPR) - Specify the rules for propagating the tags 7 load r2 ← M[r1+offset] Check Check source register r1 Check source address M[r1+offset] Propagation Only source register r1 Only source address M[r1+offset] OR / AND of source tags 32-bit Word Tag

8. RAKSHA: PIPELINE  Modified Leon SPARC V8 processor pipeline  4-bit tag in registers, caches and memory  Tag ALU propagates tags based on TPR  Tag-checker checks tags based on TCR and raises exception if needed 8 Execute Memory Exception Writeback Fetch DecodeAccess RakshaTags Raksha Logic

9. RAKSHA: SECURITY HANDLER  Runs at the same privilege level as applications in trusted mode  Handles security exception without going into OS kernel  Allows protection of OS code  Direct access to tag bits & tag instructions  Protected against malicious applications by sandboxing 9 App OS Security Handler Hardware trap Untrusted Trusted

10. EXAMPLE: SQL COMMAND INJECTION 10 MOV: Source propagation Policy #1: TPR EXEC: Instruction Check Policy #2: TCR ERROR X ‘bob’ X OR X ‘1’=‘1 Interpreter X X X SQL Code Executing SQL In HW Argument Safe? YES NO SECURITY HANDLER detected X X X SQL Functions Library X X String Tainting X Funct. Call Interposition Untagged

11. TEST SETUP  Hardware  Modified Leon SPARC V8 processor  Mapped to an FPGA board  Software  Modified Linux kernel 2.6.11  Applications (Apache, PostgreSQL, OpenSSH, …)  SPEC2000 benchmarks 11

12. SECURITY EVALUATION  Security test for low-level and high-level attacks  False positives and negatives? 12

13. PERFORMANCE EVALUATION  Performance slow down for Raksha vs OS exception handling  SPEC2000 integer benchmarks with memory corruption protection policy  Varying overheads due to different bounds checking techniques by the applications 13

14. CONCLUSION / SUMMARY  Raksha Features:  DIFT implementation with hardware support  Detects high-level and low-level attacks  Flexible security policies  Low performance overhead  Limitations  7.17% gate overhead, 12.5% memory overhead  Tagging not well defined for byte-level data  Inaccuracies in protection against memory corruption vulnerabilities 14

15. Questions? 15

16. DISCUSSION POINTS  Is the 4-bit tag enough or too much? How well will this scale for large systems?  Is Raksha (designed for unmodified binaries) suitable for protection against memory corruption vulnerabilities?  Is it safe for security handler to run at the user-level? PROCON 16

17. 17