G E N E S I S : Security Through Software Diversity

1. GENESIS: Security Through Software Diversity John C. Knight, Jack W. Davidson, David Evans, Anh Nguyen-Tuong University of Virginia Chenxi Wang Carnegie Mellon University http://www.cs.virginia.edu/genesis/

2. UVA staff Adrian Filipi Jason Hiser Jonathan Rowanhill UVA students Ben Cox Wei Hu Nate Paul Ana Sovarel Dan Williams CMU student Ting-Fang Yen Other Team Members

3. Outline • As requested, we are following the outline that John sent out • We are using his phrasing for the titles Good

4. Recall SRS Program Goal Biologically-Inspired Diversity: “Metric: automatically produce 100 diverse but functionally equivalent versions of a software component such that no more than thirty-three versions of a component share the same deficiency.”

5. Project Overview

6. Diversity Transforms Diversity Transforms Diversity Transforms Diversity Transforms Source code Source code Source code Source code Compile Compile Compile Compile Object code Object code Object code Object code Link Link Link Link Executable Executable Executable Executable Load Load Load Load Run Run Run Run Genesis Vision • Automated production of diverse functionally-equivalent software • Comprehensive application of diversity

7. STRATA Virtual Machine Apply transformations to binaries during execution Portable VM  portable encapsulation of diversity policies No source code needed Previous STRATA applications Binary translation for binary execution on non-native CPU Security policies Dynamic optimizations Diversity @ Run-time

8. Genesis Technical Approach • Practical applications of Instruction Set Randomization (code injection attacks) • Low overhead • Diversity key generated at run-time, single binary image  compatible with integrity checkers • Maintain control through attack unlike previous ISR approaches (starting point for recovery) • Source code not needed • Calling Sequence Diversity (return-to-libc attacks) • Modifies calling convention • Diversity key generated at run-time • Requires compiler support

9. Picture From July PI Meeting

10. Results

11. Security Summary • Practical protection against code injection and return-to-libc style attacks • Low overhead • Independent of code-injection exploit path: • Handles both known and unknown attacks • Breaks attack payload • No successful penetration on test applications • Using own attacks • With Red team

12. SPEC Benchmark • Avg SpecInt: 6% Avg SpecFloat: 3% • In progress: ISR measurements

13. Apache & Bind DNS Performance • Preliminary numbers • Apache performance: • [0% - 4%] • Bind performance • [5% - 10%] • Diversity transforms (i.e., AES) add little overhead beyond the base Strata Virtual Machine

14. Performance Summary • Expand benchmarks to other critical services and applications • File servers, FTP servers, mail servers, etc… • Browsers, mail clients, etc… • If performance holds (<10%): • Dynamic and continuous protection, i.e., always run software with Strata • Opens up lots of possibilities

15. Toolkit Summary

16. Toolkit Summary • Techniques implemented: • Instruction setrandomization + tagging • Calling sequence diversity • Simple address space randomization • Stack frame padding • Techniques are composable • Arbitrary number of versions

17. Toolkit Summary

18. Significant Other Results • N-Variant Systems http://www.cs.virginia.edu/nvariant/ • Security as a system property • Secretless security • NSF Cyber Trust award • PHPrevent http://www.phprevent.org/ • Web application protection • Prevents cross-site scripting, command/script injection and SQL injection attacks • Low false positive rates • Precise tainting approach applicable to other environments • Prototype performance: < 10% • PHP installed on 50% of Apache servers, 1.3M IP address, 23M domains (Apache ~70% of the web server market)

19. Red Team Exercise

20. The Blue Team

21. The White Team

22. The Red Team

23. Blue Team • 100 variants of Apache protected using combination of: • Instruction set randomization + tagging, calling sequence diversity, simple address space randomization, stack frame padding • Scope & claims • Code-injection attacks • Return-to-libc attacks • Application-level attacks

24. Red Team • Long night  sleep deprived • Attempted to launch 6 exploits against all 100 variants • 2 exploits counted,i.e., worked againstunprotected Apache

25. White Team • Verified exploit works against unprotected Apache • Count red squares (successful) vs. green squares (thwarted). Total # squares = 100. • 2 code-injection attacks via format string and buffer overflow Blue team: 198 pointsRed team: 0 points

26. Red Team Summary • Very useful activity • Red Team identified potential vulnerability in calling sequence diversity with function handlers: • Not in scope with respect to return-to-libc attacks, will address in the future • Red Team needs more time: • Exploits are brittle • Designing exploits for programs running under the Strata VM difficult • Expanded red team in progress: • Everything is in scope (VM, non-code injection attacks, non-return-to-libc attacks) • Very useful activity

27. Diversity Transforms Diversity Transforms Diversity Transforms Source code Source code Source code Compile Compile Compile Object code Object code Object code Link Link Link Executable Executable Executable Load Load Load Run Run Run Improving SRS Metrics • Expand attack classes covered by diversity techniques • Tighter definition of success needed—what is a “deficiency”? • Bounds on environmental aspects, e.g. performance—should be constrained

28. Impediments To Dramatic Performance Increase • Depends what you mean by: • “impediment” • “dramatic”, and • “performance” • There are many dimensions to this • We think they should be explored • Here is what we mean…

29. Impediments To Dramatic Performance Increase • Applicability: • Support for more platforms, e.g. Microsoft and Apple (currently supported by Strata: Solaris, Irix, Linux) • This will not be simple to create • Utility: • Ease-of-use tools and techniques • More general tools and techniques • Operational evaluation

30. Impediments To Dramatic Performance Increase • More comprehensive processes: • Support for system manufacturing • Manufacturing economics models • Cover larger class of attacks: • Insider, data, DoS, application • Further reduce overhead of various techniques: • Strata VM performance (note critical threshold) • Diversity transforms

31. Next Steps For Genesis Team • Generalize diversity techniques: • E.g., Add protection against non-control attacks • E.g., Handle “higher-level” attacks • Combine diversity and other protection mechanisms: • E.g., Generalize calling sequence diversity • E.g., Strata security policies + diversity transforms • Operational evaluation of diversity • In contact with DoD supplier • Reduce Strata overhead further • Windows Port

32. Follow-on Program • Major program for: • Demonstration • Integration • Enhancement of SRS-developed technologies • Program might: • Target typical DoD system • Involve most existing groups • Involve new groups interested in related issues

33. Artificial diversity really works It is ready for “primetime” evaluation Genesis tools can support realistic applications Low Strata performance overhead Opens up many opportunities Conclusions What an excellent project, I am delighted