06/21/01 copyright © 2001 wirex communications, inc. 1 autonomix: component, network, and system...

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


Outline

Brief recapComponent Autonomy

FormatGuard

RaceGuard

Network & System Autonomy

Babelfish

Adaptation Space

Detail recent workComponent Autonomy

PointGuard

CryptoMark

LSM: Linux Security Module

Network & System Autonomy

Experimentation


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


Component Autonomy:Technical Objectives• Family of tools to guard components against common

software vulnerabilitiesStackGuard: 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


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


Quick Review

• Results previous to this projectStackGuard: protection from “stack smashing” buffer overflows

SubDomain: lightweight mandatory access controls

• Previously reported Autonomix resultsFormatGuard: protection from printf format bugs

RaceGuard: protection from temp file races

Relative Invulnerability: empirical measurement of effectiveness of these tools, individually and in combination


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


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


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


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


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


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


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


Immunix Relative Invulnerability

All Penetration RemotePenetration

StackGuard 6/5710%

6/5311%

4/1331%

FormatGuard 6/5710%

6/5311%

2/1315%

RaceGuard 21/5737%

21/5340%

0/130%

*GuardCombination

33/5758%

33/5362%

6/1346%

Server ApplianceConfiguration

28/4070%

28/3678%

5/862%

Server Appliance+ SubDomain

32/4080%

32/3689%

8/8100%


New Stuff

• New Autonomix Component TechnologiesPointGuard: generalized StackGuard

IPGuard: protect against invalid packet sequence attacks

CryptoMark: kernel-enforced digital signatures for programs

Linux Security Module: facilitate kernel loadable security extensions


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


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


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


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


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


PointGuard Impact

PointGuard willbring these to9/13 (69%)& 6/8 (75%)

All Penetration RemotePenetration

StackGuard 6/5710%

6/5311%

4/1331%

FormatGuard 6/5710%

6/5311%

2/1315%

RaceGuard 21/5737%

21/5340%

0/130%

*GuardCombination

33/5758%

33/5362%

6/1346%

Server ApplianceConfiguration

28/4070%

28/3678%

5/862%

Server Appliance+ SubDomain

32/4080%

32/3689%

8/8100%


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


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


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


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


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


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


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



• 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.



• 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


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


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)


LSM - Architecture

• Framework is agnostic: Always push policy decisions into modulePermissive: 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


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


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


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


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


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


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


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


S.N.A.R.E Testbed(Systemic & Network Autonomic Response)

Sensors/Detectors

StackGuardEvent

Other Events

…

Orchestrator(e.g., SoSmart CBR)

NavigatorSystemState

ADF

at HiImplementationAlternatives

IPChainsvia SNMP

at Hj

Configured WithAdaptation Space(s)

TCPWrappers

at Hj

Kill FTP

at Hj

Do Nothing(e.g., hardened

or not running FTP)

at Hj

xinetd

at Hj

WindowsPersonalFirewall

at Hj

SARA

High-level directive (e.g., “shun FTP

requests from Hi on LAN”)

notify and monitor (where j i)


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


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

06/21/01 copyright © 2001 wirex communications, inc. 1 autonomix: component, network, and system...

Documents