Autonomix : Autonomic Defenses for Vulnerable Software

1. Autonomix:Autonomic Defenses for Vulnerable Software Crispin Cowan, Ph.D WireX Communications, Inc wirex.com

2. Phase I: WireX and OGI WireX: Component Autonomy Defend software implementation against common vulnerabilities OGI: Network and Systemic Autonomy IDS notification translation IDS response “orchestrate” Phase II: Just WireX More component Autonomy LSM: Linux Security Module Phase I and Phase II

3. AutonomixTechnical Objectives • Tools to guard legacy components against common software vulnerabilities StackGuard: protection from “stack smashing” buffer overflows SubDomain: lightweight mandatory access controls FormatGuard: protection from printf format bugs RaceGuard: protection from temp file races PointGuard: generalized StackGuard CryptoMark: kernel-enforced digital signatures for programs Linux Security Module: facilitate kernel loadable security extensions Objective: vulnerability tolerance

4. Technical Approach: Abstract Approach • Local intrusion response • Catch intrusion in process • Halt exploited component The Canary Technique • Detect attacks in progress: • Make symptoms of attack mode obvious • Place a sacrificial canary where an attack will show tampering • Monitor canary • If canary destroyed, then attack is happening

5. Quick Review • Results previous to this project StackGuard: protection from “stack smashing” buffer overflows SubDomain: lightweight mandatory access controls • Last Year’s Autonomix results FormatGuard: protection from printf format bugs • USENIX Security 2001 paper • Open source • In Immunix 7.0 products RaceGuard: protection from temp file races • USENIX Security 2001 paper • Didn’t quite make the product cut; in next drop Relative Invulnerability: empirical measurement of effectiveness of these tools, individually and in combination

6. Major Achievement:Low-Effort Protection • These tools are highly transparent: • Performance overhead: under 2% across the board, usually lower • Compatibility issues: minimal • Under 5% of all Linux programs need trivial source patches to compile with StackGuard and FormatGuard • RaceGuard works on binary code, breaks nothing • Administrative overhead: nil

7. Proposed Metric:Relative Invulnerability • Compare a “base” system against a system protected with Immunix tools • Count the number of known vulnerabilities stopped by the technology • “Relative Invulnerability”: % of vulnerabilities stopped

8. Immunix Relative Invulnerability • Immunix System 7: • Based on Red Hat 7.0 • Compare Immunix vulnerability to Red Hat’s Errata page (plus a few they don’t talk about :-) • October 1, 2000 - May 25, 2001 • 57 vulnerabilities total • 16 remote, 41 local • 53 penetration, 4 DoS • 13 remote penetration

9. Immunix Relative Invulnerability

10. New Stuff • Incremental work: FormatGuard: refinement to improve coverage RaceGuard: refinement to close hole • New Autonomix Component Technologies PointGuard: generalized StackGuard CryptoMark: kernel-enforced digital signatures for programs Linux Security Module: facilitate kernel loadable security extensions

11. New Stuff • Incremental work: FormatGuard: refinement to improve coverage RaceGuard: refinement to close hole • New Autonomix Component Technologies PointGuard: generalized StackGuard CryptoMark: kernel-enforced digital signatures for programs Linux Security Module: facilitate kernel loadable security extensions Today’s Focus

12. LSM: Linux Security Module • Standard Linux kernel limited to classical UNIX security model: • root is everything • POSIX.1e Capabilities • Linux kernel a common target for security research • Immunix: SubDomain, RaceGuard • Others: SELinux, RSBAC, LIDS, LOMAC, DTE, NAI Wrappers, Janus, SGI CAPP, etc.

13. LSM: Linux Security Module • Unfortunately, none are standard to Linux • Maintained as kernel patches • To deploy them, must acquire a custom kernel • Linus would like to support advanced security policy, but not willing to endorse one project. • Too political… “My security policy is better than yours.” • Linus is not a security expert, and doesn’t want to be • Linux is about choice anyway • Solution: enrich Linux’s module interface to support security policy modules

14. LSM - Design Goal • Create a general purpose framework to enable pluggable security modules • Be general enough to support existing security projects • Work with community to define each project's needs • Continue to support root/Capabilities, perhaps as a module

15. LSM Community • 470 people subscribed to LSM mailing list • Active participation (code :-) from: • WireX • SELinux (NAI) • SGI • IBM (at least three different locations) • Janus (David Wagner, UC Berkeley)

16. Constrained Design Space • LSM needs to be: • generic enough for existing security modules • simple enough to be acceptable to the Linux core maintainers • minimally intrusive patch • easy to understand code • able to support POSIX.1e capabilities

17. LSM Design • syscall interposition, i.e. wrappers at the syscall interface • not appropriate: leads to module bloat • already available by re-writing Linux syscall table • Instead, we mediate access to internal kernel objects “May subject X access object Y for operation Z?”

18. LSM - Architecture User-level process Kernel LSM Module • Open syscall • Std. error checks • Std. Security checks • LSM hook: • Complete request • Policy engine • examine context • does request pass policy? • grant or deny

19. LSM - Architecture User-level process Kernel LSM Module • Open syscall • Std. error checks • Std. Security checks • LSM hook: • Complete request • Policy engine • examine context • does request pass policy? • grant or deny

20. LSM - Architecture User-level process Kernel LSM Module • Open syscall • Std. error checks • Std. Security checks • LSM hook: • Complete request “ok with you?” • Policy engine • examine context • does request pass policy? • grant or deny

21. LSM - Architecture User-level process Kernel LSM Module • Open syscall • Std. error checks • Std. Security checks • LSM hook: • Complete request “ok with you?” • Policy engine • examine context • does request pass policy? • grant or deny Yes or no

22. Hook Style Restrictive: module may only reject a request about to be granted Permissive: module may only permit a request about to be rejected Authoritative: module may totally over-rule standard kernel logic • We chose restrictive hooks only, except for capabilities • Simplifies LSM patch for maximum acceptability to Linux community

23. Module Stacking • Strong desire to compose modules • However, composition in general is intractable • Solution: stacking left to modules that want to stack • Stackable module must export an LSM-like interface “out the back” • Stackable module responsible for composing policy by taking down-chain module’s results under advisement

24. Hook Location

25. LSM System Call • Many modules need a syscall interface for applications to talk directly to the module • LSM provides a generic syscall interface, and makes the module MUX it • lsm(unsigned int id, unsigned int call, unsigned long *args)

26. Kinds of Hooks • task hooks • program loading hooks • IPC hooks • FS hooks • network hooks • meta-hooks

27. Performance Overhead • Microbenchmark: lmbench • Tests various critical kernel functions, e.g. open, read/write, context switch, etc. • Worst case: 7% for trivial calls • Macro: Khernelstone, i.e. time to make Linux kernel • overhead not measurable • LSM version actually measured faster, but we don’t claim LSM is an optimization :-)

28. Related Work • Extensible kernels • Microkernels, SPIN, SCOUT, Synthetix, etc. • All about safety: • prevent extensions from corrupting the kernel • Insight: LSM doesn’t need that safety • System is completely at the mercy of security policy anyway • Go ahead and just trust LSM modules • Use simple dynamic linking technologies

29. Status & Modules • LSM interface implemented & stable • Linux 2.4.16 and 2.5.1, actively tracking • Modules: SELinux: NSA & NAI project to add RBAC and DTE to Linux DTE: GPL re-implementation of the classic Openwall: prevents various attacks involving symbolic and hard links POSIX.1e capabilities

30. OASIS Projects • SCC: using SELinux via LSM • Bob Balzer wants to do LSM for Windows • Wrappers might consider porting to LSM • restrictive hooks may be a problem • Others?

31. LSM - What's next • Paper submitted; pending response • Phase 1: • Submit to Linux 2.5 kernel • Pending on VFS reorg by Linux people • Phase 2: • Consider extended support for Audit • More permissive hooks beyond Capabilities? • See if Linus is interested

32. Transition of Technology Open source: StackGuard, FormatGuard, and RaceGuard are all GPL’d Commercial: • All being incorporated into WireX Server Appliance products • Server appliance: a server for dummies • Thus the need for dummy-proof security • For sale through eLinux.com, FlexiServe (UK) • Immunix OS 7.0: hardened Linux distribution • Available for purchase through wirex.com and eLinux.com • Licensed by Counterpane

33. Component Autonomy: Largely working software Running this laptop: StackGuard, FormatGuard, RaceGuard, and SubDomain Available piece wise, or integrated into Immunix OS and Immunix server appliances, at wirex.com, eLinux.com Summary

34. LSM • Web site: http://lsm.immunix.org • Mailing list: on the web site • BOF at USENIX? USENIX Security?