Oyama SSN 05

Speculative Security Checks in Sandboxing Systems: 

Speculative Security Checks in Sandboxing Systems Yoshihiro Oyama Koichi Onoue Akinori Yonezawa The University of Tokyo Japan Science and Technology Agency

Sandbox: 

Sandbox Confine untrusted applications Control/restrict accesses to resources Isolate potential damages Can be achieved with: VM: Java, .NET OS: chroot Middleware: Janus, MAPbox, SoftwarePot

Advantage and Disadvantage of Sandboxes: 

Advantage and Disadvantage of Sandboxes Advantage Enhanced security Disadvantage Overhead incurred by security checks (details explained later)

This Work: 

This Work Goal Reduce overhead of sandboxes Approach: Our sandbox SpecSB Execute speculative security checks in parallel with applications Predict behavior of applications

Outline: 

Outline Settings Problems in existing systems Our sandboxing system SpecSB Speculation Prediction of system calls Implementation details Experimental results Related work Summary andamp; future work

Security Systems Considered in This Work: 

Security Systems Considered in This Work Sandboxes/IDSes implemented by system call interception Middleware that intercepts resource accesses Example: Janus [Goldberg et al. ’96], MAPbox [Acharya et al. ’00], SoftwarePot [Kato et al. ’03], Systrace [Provos ’03] IDS [Xu et al. ’04] [Feng et al. ’03] [Sekar et al. ’01] [Wagner et al. ’00]

Behavior of Sandbox: 

Behavior of Sandbox OS sandbox application security policy

Problem: 

Problem Overhead of security checks Application suspends during security checks Entire time for checks is added to overall execution time app sandbox OS check kernel service time invoke syscall check return from syscall

But… Are They Really So Heavy?: 

But… Are They Really So Heavy? General (and useless) answer Some are heavy Others are not So let’s look at individual numbers

Sandboxing Overheads in Literature: 

Sandboxing Overheads in Literature Wagner01: Ultra-huge Xu03: 300%~500% Sekar01: 100%~250% Oka03: 52%~95% Kato03: 21%~95% Acharya00: 1%~33% Goldberg96: almost negligible large OH small OH

Why So Heavy?: 

Why So Heavy? Wagner01: Parsing syscall sequence as context-free grammar Xu03, Oka03, Sekar01: Inspecting call stack Time-consuming checks are executed during syscall interception

Observation and Hope: 

Observation and Hope Some novel algorithms are heavy But interesting and promising We will create technology that encourages to adopt novel algorithms!

Overview of SpecSB: 

Overview of SpecSB Syscall interception-based sandbox Aggressive use of multiprocessors Checks are executed in parallel with applications Future syscalls are predicted using automaton of past syscall behavior Checks are started before actual call

How SpecSB Works: 

How SpecSB Works OS application main thread speculative thread system call allow system call deny communication via shared mem. SpecSB

Structure of SpecSB: 

Structure of SpecSB main thread speculative thread prediction module check module issue speculation return results system call allow deny

Flow of Main Thread: 

Flow of Main Thread obtain syscall info andamp; prediction result is prediction correct? stop speculation perform security checks by itself no wait for completion of speculation issue next speculation yes intercept syscall resume syscall

Time Chart Changed: 

Time Chart Changed app sandbox OS

Time Chart Changed: 

Time Chart Changed app sandbox OS checking speculation result

For Successful Speculation: 

For Successful Speculation Prediction accracy is the key! Good heuristics for prediction is essential Common tendency? Programmer’s annotation? Profiles of past execution? source info for heuristics

Prediction of Syscall Info: 

Prediction of Syscall Info Use syscall profiles in past executions OS SpecSB Profiler application syscall syscall automaton representing syscall profile

Automaton: 

Automaton Node: system call has resource sysargs and don’t-care sysargs Edge: relation between two consecutive system calls labeled with same/diff same: access same resource as previous diff: access diff. resource as previous

Example of Automaton: 

Example of Automaton mmap2(,,,,R,) R=open(R,,) read(R,,) writev(R,,) write(R,,) diff:4 same:40 diff:35 diff:2 diff:82 same:1 same:1 same:4 same:29 diff:28 same:10 diff:1 created automatically from Apache 1.3.29 on Linux

Implementation Details (1)- monitoring -: 

Implementation Details (1) - monitoring - Uses ptrace() All syscalls are intercepted Creates speculative thread by clone() and CLONE_VM Two threads share address space Traces child process by forking monitoring thread Does not support multithread apps

Implementation Details (2)- self-protection -: 

Implementation Details (2) - self-protection - SpecSB protects itself from attacks by sandboxed processes SpecSB controls execution of potentially dangerous syscalls (e.g., kill()) Currently we assume SpecSB code has no vulnerability SpecSB provides no mechanism for protecting resources even when it is exploited cf. SeRene [Yoshino et al. ’04]

Discussion: Significance of Hiding Checking Overhead: 

Discussion: Significance of Hiding Checking Overhead Sandbox users’ view Slowdown due to sandboxing is reduced Sandbox developers’ view More complex/intelligent algorithm can be adopted to achieve sandboxes It promotes development of novel checking algorithms!

Experiments: 

Experiments Goal: measure the amount of speedup under various conditions Platform: 4-CPU SMP (Pentium III 700MHz) Linux 2.4.14

Microbenchmark Program: 

Microbenchmark Program for (i = 0; i andlt; 1000; i++) { stat(path, …); computation(Napp); fd = open(path, …); read(fd, …); close(fd); } security check here

Results (1): 

Results (1)

Results (2): 

Results (2)

General Trend: 

General Trend execution time security check cost no speculation speculation entire check overlaps with apps overhead due to speculation maximum benefit

Related Work (1): 

Related Work (1) Syscall interception-based sandboxes [Goldberg et al. ’96] [Acharya et al. ’00] No previous work proposed speculative/parallel security checks Speculative security check [Oplingerandamp;Lam ’02] Parallel execution of apps and checks Special hardware required Programmers’ cooperation required

Related Work (2): 

Related Work (2) Shadow Guarding [Patilandamp;Fischer ’95] Shadow process runs in parallel with app process and performs security checks Source code of apps required for generating security check code

Summary: 

Summary We proposed a method for introducing speculation to sandboxes Two threads run in parallel, cooperating via shared memory Behavior is predicted by using profiles We measured effect in experiments Speedup is confirmed

Future Work: 

Future Work Perform experiments with wide range of applications Apply proposed method to widely-used sandboxes/IDSes Modify AntiVirus? Identify effectiveness of multiple speculative threads

Thank you.: 

Thank you.