180 likes | 328 Views
Dynamic Tainting for Deployed Java Programs. Du Li Advisor: Witawas Srisa -an University of Nebraska-Lincoln. Example. Example (Cont). Dynamic Tainting Analysis. Mark and track certain data at runtime Widely applied to: Attack prevention Data lifespan/scope analysis
E N D
Dynamic Tainting for Deployed Java Programs Du Li Advisor: WitawasSrisa-an University of Nebraska-Lincoln
Dynamic Tainting Analysis • Mark and track certain data at runtime • Widely applied to: • Attack prevention • Data lifespan/scope analysis • Generation of test cases • etc.
Dynamic Tainting Analysis (cont.) • Powerful but expensive • Significant overhead • Need third-party tools support • Suitable for debugging and maintenance, too much overhead for deployed systems
Goal • Make dynamic tainting analysis feasible for deployed systems • Fast: High-performance and low overhead • Easy to use: No need for extra HW or SW support • Flexible: Users control what and when to monitor
Idea • Java Virtual Machine is a good platform for dynamic tainting analysis • Useful runtime information • CFG, data access, object life span, ... • Existing components • Barriers • Optimizing compilers • Garbage collectors
Outline • Motivation • A proposed solution • Implementation plan • Conclusion
Motivation • Existing dynamic tainting tools have high overhead • Dytan: 30-50 times overhead (Clause et al.) • Taintcheck: 20 times overhead in the worst case (Seward et al.) • Effective memory protector: 25% overhead but need special hardware (Clause et al.)
Motivation (cont.) • Existing solutions need extra SW support • Dytan: on top of PIN (Luk et al.) • TaintChecker: on top of Valgrind (Nethercote et al.) • Require users' extra effort to set up execution environment on third-party tools (not always feasible)
Motivation (cont.) • Existing work is based on binary instrumentation • Managed languages (like Java) are popular in many deployed environments • It is time to investigate tainting analysis in virtual machines
Solution • JVM-based Dynamic Tainting framework • Easy to use: as one JVM build-in feature, no need for extra tool support, enable by setting a flag • High-performance: utilize existing runtime systems to generate information • Customization: can be configurable to monitor only a subset of data flow
Implementation • JVM has useful infrastructure for dynamic tainting analysis • Read/Write barriers → data access tracing • Garbage collector → marking information process • JIT compilers → optimization
Implementation (cont.) • Data tracing • Write/Read Barriers can monitor all data access efficiently • Garbage collector can help to identify data references • Our experiment and existing work (Blackburn et al.) shows average overhead of barriers can range from 6.49% to 21.24% • Data tracing is the dominant part of overhead
Implementation (cont.) • Achieving High-Performance • JIT compiler is a great place to improve performance • All tainting analysis related code will be optimized by JIT compiler • Data dependency information can be generated by JIT compiler • Make tainting process more accurate and smart
Implementation (cont.) • Achieving Customization • JIT compiler can replace code at runtime • Our framework makes use of JIT compiler to customize tainting analysis sampling rate, granularity, or even turn on/off tainting analysis • Tradeoff between accuracy and performance
Status • Working on Maxine Virtual Machine to build data flow analysis framework • Basic components are close to be done • Plan to build tainting analysis on top of the framework
Conclusion • Existing tainting analysis solution is powerful but heavy weight • JVM base tainting framework is easier to use: efficient, flexible • Existing JVM infrastructure can help to improve tainting process