Dynamic Program Security Aaron Roth Ali Sinop Gunhee Kim Hyeontaek Lim

Security Attacks Software that deals with input is potentially vulnerable to attacks: Low-level Attacks: –Buffer Overflows: Writing data without bounds checking can corrupt adjacent memory locations. Can overwrite return pointer and hijack control flow…

Security Attacks Semantic Attacks: –Everything looks ok at the low-level, but… SELECT Userlist.Username FROM Userlist WHERE Userlist.Username = ‘Username’ AND Userlist.Password = ‘Password’ SELECT Userlist.Username FROM Userlist WHERE Userlist.Username = ‘Username’ AND Userlist.Password = ‘Password’ OR ‘1’=‘1’

Solution? Tracking untrusted information –Assign a ‘taint bit’ to every word of memory. Set to 1 if it came from an untrusted source, or if it was derived from an untrusted register. –Throw a security exception if something dangerous is done with a tainted word: Instruction Execution Pointer Dereferencing … DONE!

Problems? A Naïve software implementation of this is slow… (up to 37x slowdown) –Remember PIN? A hardware-only implementation risks lots of false negatives/false positives –Doesn’t know about program semantics, or when data has been verified to be safe Solution?

Raksha: A Flexible Information Flow Architecture for Software Security Michael Dalton, Hari Kannan and Christos Kozyrakis Computer Systems Laboratory, Stanford University ISCA 2007

Prior Work Software-based methods: + Flexible –Either require access to source code [Xu et al’06] or, –Binary instrumentations lead to slowdowns from 3x to 37x [Qin et al’06, Newsome & Song’05] –Not safe with multi-threading [Qin et al’06] Hardware-based methods: + Fast –Hardcoded security policies –Can’t prevent high-level attacks [Dalton et al’06]

Basic Approach Taint propagation mechanism as mentioned earlier (dynamic information flow): –Extend all storage by 4-bit tag bits at 32-bit word level. –One bit for each policy –Each instruction is given one or more classes: –Floating Point –Move –Integer Arithmetic –Comparisons –Logical –TPR: Tag Propagation Registers for each active security policy (=4) –Designates how to compute the result tag from source tag(s) –for each instruction class –Certain instructions can untaint data: Example: –Buffer overwrite: Bounds checking by comparison [Chen et al’05]

Basic Approach (2) –Checking for security violations: –TCR: Tag Check Registers for each active security policy (=4) –Specifies which operands should be checked for tag exception. –Also handles corner cases (false positives): –Should XOR r1, r1, r1 make r1 untainted?

Even more Raksha Trusted processor mode –Access to security policy TPR and TCR registers User-defined security handler –Raised when an unsafe operation is executed on a tainted operand –Should distinguish false-positives –Efficient because no kernel/user mode switch

Results ProgramLanguageAttackDetected Vulnerability gzipCDirectory traversal Open file with tainted absolute path ScryPHPCross-site scriptingTainted HTML output includes ProFTPDCSQL injectionUnescaped tainted SQL query polymorphCBuffer overflowTainted code pointer dereference (return address) ProgramRaksha Slowdown bzip21.33x crafty1.00x gap1.12x

Flexible Hardware Acceleration for Instruction-Grain Lifeguards Shimin Chen 1, Michael Kozuch 1, Theodoros Strigkos 2, Babak Falsafi 3, Phillip B. Gibbons 1, Todd C. Mowry 1,2, Vijaya Ramachandran 4, Olatunji Ruwase 2, Michael Ryan 1, Evangelos Vlachos 2 1 Intel Research Pittsburgh 2 CMU 3 EPFL 4 UT Austin ISCA 2008

Flexible Hardware Acceleration for Instruction-Grain Lifeguards Dynamic Monitoring Tool (during application execution) Ex. Memory access, Data Flow

Flexible Hardware Acceleration for Instruction-Grain Lifeguards Dynamic Monitoring Tool (during application execution) Ex. DBI: 10~100 times Slowdown Ex. Memory access, Data Flow

Flexible Hardware Acceleration for Instruction-Grain Lifeguards Ex. DBI: 10~100 times Slowdown Applications/bugs, attacks are always changed Ex. Memory access, Data Flow Dynamic Monitoring Tool (during application execution)

Summary Fast and Flexible Lifeguard Specific Lifeguard General Purpose: Wide Range of Lifeguards Dynamic binary instrumentation (DBI) X slowdowns General-Purpose HW improving DBI 3-8X slowdowns Lifeguard-specific hardware This paper Performance Good Poor [Bruening’04] [Luk et al’05] [Nethercote’04] [Crandall & Chong’04], [Dalton et al’07], [Shetty et al’06], [Shi et al’06], [Suh et al’04], [Venkataramani’07], [Venkataramani’08], [Zhou et al’07] [Chen et al’06] [Corliss’03] [Source]

Approach Identify three main sources of lifeguard overhead –Propagation-style metadata updates –Metadata checks –Matadata mapping Propose three hardware acceleration techniques –Inheritance tracking (IT) –Idempotent filters (IF) –Metadata-TLBs (M-TLB) Log-based architecture (LBA)

Results AddrCheck TaintCheck TaintCheck w/ detailed tracking LockSet MemCheck BASE MTLB MTLB+IF BASE MTLB MTLB+IT MTLB+IT+IF BASE MTLB MTLB+IT BASE MTLB MTLB+IT BASE MTLB MTLB+IF average slowdowns [Source]

Discussion Dynamic checking seems to be good… Let’s check dynamic checking!

Who Checks? Software only –Adaptable to new types of checking –Very slow Mostly hardware –Low overheads –Specialized & needs more complex hardware HW checks, but SW analyzes ([Dalton et al’07]) SW checks, but HW accelerates ([Chen et al’08]) Other hybrid methods?

What Does It Check? Hand-written invariants –Time consuming to write –Error-prone –Can be another source of bug & security problems! Automatically finding invariants?

When Does It Check? Immediately checking –Blocks main execution when handling security exception ([Dalton et al’07]) –Stops any error propagation if found –Makes unnecessary latency for false-positives Not immediately checking –Records execution log & check it ([Chen et al’06,’08]) –Can hide latency & utilize idle/multiple cores –May be too late to stop error propagation Some hybrid methods?

Conclusion Dynamic checking –Promising solution to detect security attacks –Abundant research opportunities