Parallelizing Security Checks on Commodity Hardware

1. Parallelizing Security Checks on Commodity Hardware Ed Nightingale Dan Peek, Peter Chen Jason FlinnMicrosoft Research University of Michigan

2. Run-time security checks • Provide run-time intrusion detection/prevention • Many powerful checks have been proposed • Examples: Taint-analysis, on-access virus scanning, system call graph modeling • Often impose high performance penalties • What makes run-time checks slow? ASPLOS 2008

3. Problem Application & security check Application A A Begin application PAUSE B Pause execution 3) Run security check C 4) Resume application RESUME D B PAUSE RESUME C PAUSE RESUME D PAUSE ASPLOS 2008 • Checks may slow performance by 10x

4. Solution • Speck (Speculative parallel check) • Parallelize checks across many cores • Provide security equivalent to sequential check • Use three techniques • Transparent kernel replay system • Operating system support for speculative execution • Buffer dependent output until checks complete ASPLOS 2008

5. Accelerating checks with Speck cpu0 cpu1 cpu2 cpu3 cpu4 A Speculate! B C D • 1) Run process speculatively • Speed of parallelization without sacrificing safety! • 3) Start later checks in parallel to earlier ones ASPLOS 2008 2) Execute check in parallel

6. Outline Introduction Implementing Speck Parallelizing security checks ASPLOS 2008

7. Example: Executing sequentially A PAUSE • All state ‘frozen’ and available to security check • Examples – heap, address space, file name, system call, value of a single address in memory ASPLOS 2008

8. Example: Executing in parallel cpu0 cpu1 A fork() • Speck uses fork() to copy state to other core How does security check get app state? ASPLOS 2008

9. Example: Executing in parallel cpu0 cpu1 cpu2 A B fork() epoch 0 C D B fork() E epoch 1 F E C F • Amortize fork by grouping checks into epochs • What happens when app interacts with OS? ASPLOS 2008

10. Safely executing system calls • Some system calls affect state of calling process • Introduces non-determinism in execution • Other system calls may affect other processes • Other processes may be compromised as well • Some system calls generate output • Output to screen or network cannot be undone ASPLOS 2008

11. Replaying non-determinism data data Inst Clone UninstProcess Execute read() Execute read() OS • Speck replays system calls that affect process state • Some system calls (mmap) re-executed • Signal delivery limited to exit from system call • Prevents instrumented clone from diverging ASPLOS 2008

12. Tracking causal dependencies • Speculator [sosp05] tracks causal dependencies • Supports FIFOs, pipes, UNIX sockets etc. • Undo log associated with each object • Do not handle multi-threading (MP replay hard) • All dependent objects rolled back on failure • Uninstrumented process terminated on failure • Uninstrumented process can safely run ahead ASPLOS 2008

13. Handling output commits • Problem: Some system calls create output • Output to network or screen buffered • When all checks within epoch complete dependent output released ASPLOS 2008

14. Equivalence/Safety • Assume attacker cannot compromise • Speck in-kernel replay system • Speculator in-kernel causal dependency tracking • Replay system ensures code equivalence • Instrumented clone does not diverge • Speculator prevents permanent damage • Speculator rolls back all dependent state on failure ASPLOS 2008

15. Outline Introduction Implementing Speck Parallelizing security checks ASPLOS 2008

16. Choosing security checks • All checks depend upon uninstrumented process • Amount of state determines Speck strategy • Some checks require little state or run infrequently • No need for fork and replay…just pause app and ship state • Some checks depend upon result of earlier check • Independent checks easy to parallelize • Many dependencies make parallelization harder • Example: taint analysis ASPLOS 2008

17. Using Speck to parallelize checks • Process memory analysis • Sensitive data leaks • System call analysis • On-access virus scanner • Data flow analysis • Taint analysis ASPLOS 2008

18. Process Memory Analysis • Checking for transient leaks of sensitive data • Our check examines every memory store • Looks for signature of sensitive data • Examines all 16 byte windows around address • Use Pin dynamic binary rewriting tool • Later checks do not depend on earlier checks ASPLOS 2008

19. MPlayer video decoding • Speck 7.5x faster with 8 cores • Video plays in real time ASPLOS 2008

20. On-access virus scanner • Scan files on-access by a process • Many different policies -- on-read on-write etc. • Our check scans each file on-close • Emulates news/email server • Implemented using ClamAV libraries (180K sigs) • Little state is required and checks independent • Speck does not use fork and replay for this check ASPLOS 2008

21. PostMark benchmark 2.8x more TPS ASPLOS 2008

22. Taint analysis • Trace flow of data from untrusted sources • Instrument application at instruction granularity • Update map of tainted addresses at run-time • Ensure certain addresses are not tainted • Later checks depend on result of earlier checks • Running in parallel cannot tell whether address was tainted during prior check ASPLOS 2008

23. Parallelizing taint analysis …cpu n cpu0 cpu1 cpu2 fork() A A B fork() C C D B D log log ASPLOS 2008 New algorithm minimizes sequential processing

24. Dynamic taint compression • Dependency logs were very large • Time to process longer than to run sequential check • Only care about dependencies before check • Addresses and registers often overwritten • Eliminate unimportant dependencies • Reduce log size 6x ASPLOS 2008

25. Taint analysis: MPlayer • 2x speedup on 8-cores ASPLOS 2008

26. Choosing a strategy • Fork & replay – need to attach check at fork • No fork & replay – need to accept concurrent requests ASPLOS 2008

27. Conclusion • Run-time security checks can be slow • Speck accelerates run-time checks • Parallelizing across many cores • Provides safety of executing checks sequentially ASPLOS 2008