1. 06/21/01 Copyright © 2001 WireX Communications, Inc. 1 Autonomix: Component, Network, and System Autonomy Crispin Cowan, Ph.D WireX Communications, Inc wirex.com David Maier & Lois Delcambre Oregon Graduate Institute of Science & Technology

2. 06/21/01 Copyright © 2001 WireX Communications, Inc. 2 Outline Brief recap Component Autonomy FormatGuard RaceGuard Network & System Autonomy Babelfish Adaptation Space Detail recent work Component Autonomy PointGuard CryptoMark LSM: Linux Security Module Network & System Autonomy Experimentation

3. 06/21/01 Copyright © 2001 WireX Communications, Inc. 3 Recap: Component, Network, and System Autonomy Component Autonomy Tight loop Complete loop: –Detection –Decision –Response –Spins off intrusion events WireX Network and System Autonomy Network: Infrastructure tool –IDS event and response protocol translator System: Orchestrator –Adaptation Space OGI

4. 06/21/01 Copyright © 2001 WireX Communications, Inc. 4 Component Autonomy: Technical Objectives Family of tools to guard 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 IPGuard: protect against invalid packet sequence attacks CryptoMark: kernel-enforced digital signatures for programs Linux Security Module: facilitate kernel loadable security extensions Objective: vulnerability tolerance

5. 06/21/01 Copyright © 2001 WireX Communications, Inc. 5 Technical Approach: Abstract Approach –Local intrusion response –Catch intrusion in process –Halt exploited component The Canary Technique Detect attacks in progress: –Place a sacrificial canary where an attack will show tampering –Monitor canary If canary destroyed, then attack is happening

6. 06/21/01 Copyright © 2001 WireX Communications, Inc. 6 Quick Review Results previous to this project StackGuard: protection from “stack smashing” buffer overflows SubDomain: lightweight mandatory access controls Previously reported Autonomix results FormatGuard: protection from printf format bugs RaceGuard: protection from temp file races Relative Invulnerability: empirical measurement of effectiveness of these tools, individually and in combination

7. 06/21/01 Copyright © 2001 WireX Communications, Inc. 7 StackGuard Problem: buffer overflow vulnerabilities Solution: –Compiler enhancement to detect & halt exploitation of buffer overflows –Approach: integrity check activation records Status: –Complete, working since 1998 –Being forward-ported to GCC 3.0

8. 06/21/01 Copyright © 2001 WireX Communications, Inc. 8 SubDomain Problem: vulnerable over-privileged programs run as root Solution: –Confine programs to a limited set of files Status: –Complete, working since 1999, published in December 2000

9. 06/21/01 Copyright © 2001 WireX Communications, Inc. 9 FormatGuard Problem: printf format string vulnerabilities Solution: –Compile-time CPP macro and wrapper to do argument counting on printf -like function calls Status: –Complete, working since October 2000 –Paper at USENIX Security 2001, August, DC

10. 06/21/01 Copyright © 2001 WireX Communications, Inc. 10 RaceGuard Problem: temporary file race vulnerabilities Solution: detect races in progress –Cache stat() calls that probe for existence of files –Detect creat() calls that match stat() calls, and hit existent files Status: –Complete, working since February 2001 –Paper at USENIX Security 2001, August, DC

11. 06/21/01 Copyright © 2001 WireX Communications, Inc. 11 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, currently breaks nothing –Administrative overhead: nil

12. 06/21/01 Copyright © 2001 WireX Communications, Inc. 12 Major Achievement: Relative Invulnerability Proposed metric: –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

13. 06/21/01 Copyright © 2001 WireX Communications, Inc. 13 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

14. 06/21/01 Copyright © 2001 WireX Communications, Inc. 14 Immunix Relative Invulnerability

15. 06/21/01 Copyright © 2001 WireX Communications, Inc. 15 New Stuff New Autonomix Component Technologies PointGuard: generalized StackGuard IPGuard: protect against invalid packet sequence attacks CryptoMark: kernel-enforced digital signatures for programs Linux Security Module: facilitate kernel loadable security extensions

16. 06/21/01 Copyright © 2001 WireX Communications, Inc. 16 PointGuard Generalization of StackGuard –StackGuard protects return address value in activation records –PointGuard protects all pointers Innovative method: the zero space canary –XOR all pointers with a random canary as they are moved from memory to registers & back again

17. 06/21/01 Copyright © 2001 WireX Communications, Inc. 17 PointGuard Implementation Dig into the GCC type system –Mediate all loads & stores of pointers Leveraging a project called “Bounded Pointers” –BP makes a pointer a tuple, checks range on each access –PointGuard’s XOR is faster –XOR less intrusive: data structures don’t change size

18. 06/21/01 Copyright © 2001 WireX Communications, Inc. 18 PointGuard Current Status Mid-way through implementation: –Changing BP’s code generator to emit XOR code instead of bounds checking code Slow going: modifying deep guts of GCC is hard: –Large –Complex –Poorly documented –Moving target

19. 06/21/01 Copyright © 2001 WireX Communications, Inc. 19 PointGuard Future Issues Dealing with non-PointGuard code –Kernel system calls –Mixed libraries –GOT: Global Offset Table Project is long, slow –May not finish without option

20. 06/21/01 Copyright © 2001 WireX Communications, Inc. 20 PointGuard Impact StackGuard used to get most buffer overflows, but declining –Attackers have mined out many stack overflows –New stuff overflows buffers on the heap, static data PointGuard will stop all currently known buffer overflows Compromise: intrusion detection event no longer pretty –Application dumps core instead of a clear-cut syslog event

21. 06/21/01 Copyright © 2001 WireX Communications, Inc. 21 PointGuard Impact PointGuard will bring these to 9/13 (69%) & 6/8 (75%)

22. 06/21/01 Copyright © 2001 WireX Communications, Inc. 22 Code Red vs. Immunix Could Immunix have stopped Code Red? –No, not directly: Immunix is for Linux, Code Red is for Windows However: Immunix can stop similar worms for Linux –StackGuard & FormatGuard stopped all three vulnerabilities in the “Ramen” worm –StackGuard & PointGuard would have stopped the vulnerabilities in the “Lion” worm

23. 06/21/01 Copyright © 2001 WireX Communications, Inc. 23 CryptoMark Problem: malicious code –Trojans, sniffers, DDoS zombies Solution: Digital certificates for programs –Platform vendor or site admin has a private key, signs all executables to be run –Platform stores the public key, checks certificate on each program as it executes –Unauthorized injected code doesn’t get to run

24. 06/21/01 Copyright © 2001 WireX Communications, Inc. 24 CryptoMark Trust Models Meta key: the Authenticode model –Microsoft signs keys used by software vendors –Vendors distribute whatever they want, and it is marked “certified” –Problem: there are hundreds of MS Certified vendors, and you have to trust all of them Single key: only one key signs all programs –Limited flexibility: only one distributor of software –Enhanced security: don’t have to worry about rogue key holders –Good for fixed purpose appliances

25. 06/21/01 Copyright © 2001 WireX Communications, Inc. 25 CryptoMark Implementation & Status CryptoMark 1.0: used GPG crypto software –Difficult to use, because it’s not a library –Slow: CryptoMark 1.0 imposes 200% to 500% overhead CryptoMark 2.0: using OpenSSL –This really is a library –RSA public key should be faster than El Gamal –Work in progress, should be done soon

26. 06/21/01 Copyright © 2001 WireX Communications, Inc. 26 IPGuard Problem: Invalid packet sequence DoS attacks –E.g. Ping of Death, Land, Teardrop, etc. Attacks are actually weak integrity attacks: –Force kernel to crash by exploiting an assumed property of network input –Ping of Death: simple datagram > 64KB in length –Nestea, Teardrop: inconsistent fragmented sequence of packets

27. 06/21/01 Copyright © 2001 WireX Communications, Inc. 27 IPGuard Proposed Solution Modular error recovery within a monolithic kernel –Consider the network stack to be an isolated module –Flip status bit whenever kernel is “in” the network stack –Mediate panic(): if seg fault reference, and kernel was “in” network stack, then try resetting the network code instead of rebooting the machine

28. 06/21/01 Copyright © 2001 WireX Communications, Inc. 28 IPGuard Issues & Status Issues: –May generalize to making many parts of a monolithic kernel recoverable –Hard to make components sufficiently isolated to recover individually Status: –Deferred in favor of LSM –Probably won’t emerge without option

29. 06/21/01 Copyright © 2001 WireX Communications, Inc. 29 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 –SELinux, RSBAC, LIDS, LOMAC, DTE, NAI Wrappers, Janus, SGI CAPP, etc.

30. 06/21/01 Copyright © 2001 WireX Communications, Inc. 30 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

31. 06/21/01 Copyright © 2001 WireX Communications, Inc. 31 LSM - Design Goal Create a general purpose framework to enable pluggable security modules –Be general enough to support existing security projects Janus, LIDS, SELinux, SubDomain, RSBAC, DTE, SGI CAPP, etc. –Work with community to define each project's needs –Continue to support root/Capabilities, perhaps as a module

32. 06/21/01 Copyright © 2001 WireX Communications, Inc. 32 LSM Community 470 people subscribed to LSM mailing list Active participation (code :-) from: –WireX –SELinux (NAI) –SGI –Harvey Mudd College –Janus (David Wagner, UC Berkeley)

33. 06/21/01 Copyright © 2001 WireX Communications, Inc. 33 LSM - Architecture Framework is agnostic: Always push policy decisions into module Permissive: grant access where kernel would have denied Restrictive: deny access where kernel would have granted Interpose at kernel object access rather than strictly syscall interface –Add opaque security ID to each object

34. 06/21/01 Copyright © 2001 WireX Communications, Inc. 34 LSM - What we have now A general hook method: a structure of function pointers –Pervasive hook placement in VFS layer –IPC and sockets under construction Permissive hooks provide coarse granularity (place hook in capabilities as foundation) –32 bit vector, i.e. capable(CAP_SYS_NICE) Restrictive hooks provide fine granularity –Free form argument list, i.e. setnice(task, nicval) Ability to load a security module to enforce a specific policy, i.e. POSIX.1e Capabilities Ability to stack modules to allow module dependency

35. 06/21/01 Copyright © 2001 WireX Communications, Inc. 35 LSM - What's next Phase 1: –Complete support for access control modules –Submit to Linux 2.5 kernel Phase 2: –Consider extended support for Audit –More permissive hooks beyond Capabilities? –See if Linus is interested

36. 06/21/01 Copyright © 2001 WireX Communications, Inc. 36 Task schedule FormatGuard: delivered RaceGuard: lab prototype works –delivered to DARPA for experimentation –should be in Immunix OS 7.1 by fall 2001 PointGuard: long-term development CryptoMark: expect to deliver in Fall 2001 IPGuard: starving Integrated Drop: prototype delivered, now available for commercial sale LSM: under development

37. 06/21/01 Copyright © 2001 WireX Communications, Inc. 37 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, eBiz, FlexiServe (UK) –Immunix OS 7.0: hardened Linux distribution Available for purchase through wirex.com and eLinux.com Licensed by Counterpane

38. 06/21/01 Copyright © 2001 WireX Communications, Inc. 38 Network and System Autonomy (OGI) Network Abstract utility for translating data representations Application: translate incompatible IDS events and responses System Adaptation Space: formal model for reasoning about alternative implementations

39. 06/21/01 Copyright © 2001 WireX Communications, Inc. 39 Network Autonomy: Technical Objective What we are trying to accomplish: –Support a single autonomic response environment that easily accommodates sensors, detectors, analyzers (e.g. an orchestrator) and responders that communicate using a variety of languages/protocols

40. 06/21/01 Copyright © 2001 WireX Communications, Inc. 40 Experiment: Shunning an FTP Client Scenario: –Attacker has compromised a node within our LAN –Now attacking internal FTP servers –StackGuard or FormatGuard intrusion events occurring Response: “shun” that node from FTP servers

41. 06/21/01 Copyright © 2001 WireX Communications, Inc. 41 S.N.A.R.E Testbed (Systemic & Network Autonomic Response) Sensors/ Detectors StackGuard Event Other Events … Orchestrator (e.g., SoSmart CBR) Navigator System State ADF at H i Implementation Alternatives IPChains via SNMP at H j Configured With Adaptation Space(s) TCP Wrappers at H j Kill FTP at H j Do Nothing ( e.g., hardened or not running FTP) at H j xinetd at H j Windows Personal Firewall at H j SARA High-level directive (e.g., “shun FTP requests from H i on LAN”) notify and monitor (where j  i)

42. 06/21/01 Copyright © 2001 WireX Communications, Inc. 42 Experiment: Shunning an FTP Client Shunning options: –ADF firewall NIC: can shun the bad node at that node –TCP Wrappers or other “Personal Firewalls”: requires telling everyone else on the LAN to shun the bad node Adaptation space: chooses the “best” implementation, depending on what is available

43. 06/21/01 Copyright © 2001 WireX Communications, Inc. 43 Summary Component Autonomy: –Largely working software –Running this laptop: StackGuard, FormatGuard, RaceGuard, and SubDomain –Coming soon: CryptoMark –Coming eventually: PointGuard, IPGuard, LSM –Available piece wise, or integrated into Immunix OS and Immunix server appliances, at wirex.com, eLinux.com Network & System Autonomy: –Largely a work in progress