Autonomix : Autonomic Defenses for Vulnerable Software

02/03/14 Copyright © 2002 WireX Communications, Inc. 1

Autonomix:Autonomic Defenses for Vulnerable Software

Crispin Cowan, Ph.D

WireX Communications, Inc

wirex.com


Phase I and Phase II

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


AutonomixTechnical Objectives• Tools to guard legacy 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

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:

– 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


Quick Review

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

SubDomain: lightweight mandatory access controls

• Last Year’s Autonomix resultsFormatGuard: 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


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


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


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

• Incremental work:FormatGuard: refinement to improve coverage

RaceGuard: refinement to close hole

• New Autonomix Component TechnologiesPointGuard: generalized StackGuard




New Stuff

• Incremental work:FormatGuard: refinement to improve coverage

RaceGuard: refinement to close hole

• New Autonomix Component TechnologiesPointGuard: generalized StackGuard



Today’s Focus


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.


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


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


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)


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


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?”


LSM - Architecture

User-level process

KernelLSMModule

Open syscall•Std. error checks•Std. Security checks•LSM hook:•Complete request

Policy engine•examine context•does request pass policy?•grant or deny


LSM - Architecture

User-level process

KernelLSMModule




LSM - Architecture

User-level process

KernelLSMModule



“ok with you?”


LSM - Architecture

User-level process

KernelLSMModule



“ok with you?”

Yes or no


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


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


Hook Location

Structure ObjectTask_struct Task (process)Linux_binprm ProgramSuper_block FilesystemInode Pipe, File, or SocketFile Open FileSk_buff Network Buffer (Packet)Net_device Network DeviceKern_ipc_perm Semaphore, Shared

Memory Segment, orMessage Queue

Msg_msg Individual Message


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)


Kinds of Hooks

• task hooks

• program loading hooks

• IPC hooks

• FS hooks

• network hooks

• meta-hooks


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 :-)


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


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


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?


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


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


Summary

• 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


LSM

• Web site: http://lsm.immunix.org

• Mailing list: on the web site

• BOF at USENIX? USENIX Security?

Documents

Autonomix : Autonomic Defenses for Vulnerable Software