1 / 34

Autonomix : Autonomic Defenses for Vulnerable Software

Autonomix : Autonomic Defenses for Vulnerable Software. Crispin Cowan, Ph.D WireX Communications, Inc wirex.com. Phase I: WireX and OGI WireX: Component Autonomy Defend software implementation against common vulnerabilities OGI: Network and Systemic Autonomy IDS notification translation

kiana
Télécharger la présentation

Autonomix : Autonomic Defenses for Vulnerable Software

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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?

More Related