1 / 23

Dynamic Program Security

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.

oakley
Télécharger la présentation

Dynamic Program Security

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Dynamic Program Security Aaron Roth Ali Sinop Gunhee Kim Hyeontaek Lim

  2. 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…

  3. 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’

  4. 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!

  5. 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?

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

  7. 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]

  8. 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]

  9. 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?

  10. 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

  11. Results

  12. Flexible Hardware Acceleration for Instruction-Grain Lifeguards Shimin Chen1, Michael Kozuch1, Theodoros Strigkos2, Babak Falsafi3, Phillip B. Gibbons1, Todd C. Mowry1,2, Vijaya Ramachandran4,Olatunji Ruwase2, Michael Ryan1, Evangelos Vlachos2 1Intel Research Pittsburgh 2CMU 3EPFL 4UT Austin ISCA 2008

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

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

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

  16. Dynamic binary instrumentation (DBI)10-100X slowdowns General-Purpose HW improving DBI3-8X slowdowns Lifeguard-specific hardware This paper Summary • Fast and Flexible Lifeguard Good [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] Performance [Source] http://www.ece.cmu.edu/~tstrigko/papers/LBA-isca08-final.ppt [Chen et al’06] [Corliss’03] [Bruening’04] [Luk et al’05][Nethercote’04] Poor General Purpose: Wide Range of Lifeguards Specific Lifeguard

  17. 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)

  18. Results 10.0 TaintCheck MemCheck TaintCheck w/ detailed tracking AddrCheck LockSet 9.0 7.80 8.0 7.0 6.05 6.0 average slowdowns 5.0 4.25 4.21 3.81 4.0 3.36 3.27 3.23 3.20 2.71 3.0 2.29 1.90 2.0 1.51 1.40 1.36 1.02 1.0 0.0 MTLB MTLB MTLB MTLB MTLB BASE BASE BASE BASE BASE MTLB+IT MTLB+IF MTLB+IT MTLB+IF MTLB+IT MTLB+IT+IF [Source] http://www.ece.cmu.edu/~tstrigko/papers/LBA-isca08-final.ppt

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

  20. 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?

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

  22. 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?

  23. Conclusion • Dynamic checking • Promising solution to detect security attacks • Abundant research opportunities

More Related