Title: Collaborative%20learning%20for%20security%20and%20repair%20in%20application%20communities%20MIT%20
1Collaborative learningfor security and repairin
application communitiesMIT DeterminaPM Lee
Badger DARPATech, August 2007 (Other AC
performer SRI)
Self-defendingCOTS Software
Approved for Public Release, Distribution
Unlimited - Case 9649
2Application Communities
- Many communities have largely identical
installations (e.g., Windows, Office)? - Problem A single vulnerability can be exploited
throughout the community - Goal Protection against exploitation of known
or unknown software vulnerabilities in
communities of COTS components - Automatically (no need for pre-generated
signature) - Protect first
- Survive and maintain functionality
3Collaborative learning approach
- Initially all community members are susceptible
to an unknown attack - Perform machine learning to infer normal behavior
- When an attack occurs
- Detect attacks on any member of the community
- Analyze additional attacks to localize
- Generate potential fixes
- Evaluate fixes
- Distribute successful fixes
- Finally all community members are automatically
protected from the attack
4The CommunityA Problem and an Opportunity
- A community contains many vulnerable members
- A community also has significant advantages
- Increased Accuracy A community exercises more
behaviors during learning - Amortized Risk A problem in one member can lead
to a solution for the rest - Shared Burden Use expensive monitoring
techniques by distributing the burden across the
members
5Collaborative Learning Framework
- Provide best possible out-of-box proactive
protection against vulnerabilities - Protect (and take advantage of) a community
- Automatically repair vulnerabilities for improved
continuity - Use dynamically learned constraints
- Key Features
- Proactive protection (Memory Firewall) for
unknown vulnerabilities - Attack detector based constraint checking focuses
repair on exploited vulnerabilities - Code injection and Denial of Service (crashes)
vulnerabilities are protected and repaired - Other detectors can be added to the framework
- Supports arbitrary x86 binaries
- Adaptive Repairs that perform poorly are removed
6Collaborative Learning System Architecture
Patch/Repair results
Patch/RepairCode Generation
Merge Constraints (Daikon)?
Patches
Constraints
Central Management System
Patches
Patches
Client Workstations (Learning)?
Client Workstations (Protected)?
7Protection Stages
- Learning Constraints are learned throughout the
community - Monitoring Applications are monitored for
attacks (Memory Firewall and crashes). - Logging Constraints near attack locations are
analyzed. Repairs are generated for constraint
violations that are correlated with attacks. - Repair Evaluation Effective repairs are
distributed, ineffective repairs are discarded.
8x lt 18
x lt 20
x lt 14
Merge Constraints
x lt 20
9Security Server
10Constraint/Attack Information
Constraint Information
Security Server
11Constraint/Repair Information
Distribute possible repairs
Security Server
12Patch Activation Information
Distribute most successful repair(s)?
Security Server
13Learning
- Applications are instrumented throughout the
community - Only a small percentage of an application is
instrumented on each machine - Constraints are found locally and then merged
centrally - Constraints are learned at the basic block level
- Variables from multiple basic blocks in a
function can be used - Loop invariants and flow dependent invariants can
be found - Built on Determinas client library
- Low overhead
- No visible change to client programs
14Monitoring detect attacks/bugs
- Current detectors
- Code injection (Determinas Memory Firewall)?
- Crashes (denial of service)?
- Address violations
- Divide by zero
- Assertion checks
- Low overhead, no false positives
- Constraint violations are not an attack!
- Attack locations are sent to central server
- Framework supports additional detectors
- Unusual code execution
- Heap consistency checker
- User complaints
15Memory Firewall as Detector
- ENTER
- Monitoring is simple
- Port monitoring or system call monitoring
- Dont know good guy from bad guy
- Only known criminals can be identified
- Even known bad guys are hard to detect
- Encrypted channels
- Used by IDS, Application Firewalls
- HIJACK
- Catch in the act of criminal behavior
- All programs follow strict conventions
- ABI (Application Binary Interface)?
- The Calling Convention (MS/Intel)?
- Currently no enforcement
- All attacks violate some of these conventions
- COMPROMISE
- Monitoring can be done
- System call monitoring
- Hard to distinguish between actions of a normal
program vs. a compromised program
Make payment
Read statement
Change prefs
ENTER
NETWORK
Attack Code
HIJACK Program Counter
1) NO ABI Violation
jmp
2) NO ABI Violation
3) ABI Violation
SYSTEM APPLICATION MEMORY
COMPROMISE
KERNEL
Write Record
Update Registry
Open port
16Memory Firewall Security Policies
- Goal Closest approximation to programmer intent
- Infer Control Flow Graph nodes and edges
- ISA requirements x86 minimal
- OS requirements page RW-
- ABI requirements imports, exports, SEH
- Calling conventions (inter-module)?
- Compiler idiosyncrasies C, gcc C, C, VB,
Delphi - Restricted Code Origins
- Prevent code injection
- Restricted Control Transfers
- Prevent code reuse attacks
- For x86 User mode
- RET
- IND CALL
- IND JUMP
17Logging - Correlate constraints and attacks
- Logging is enabled for constraints related to the
attack across the community - Overhead is low
- only related constraints are enabled for logging
- distribute logging over the community
- Send results to a central server for analysis
- A critical constraint is one that is violated if
and only if there is an attack - Repairs are created for each critical constraint
- There may be more than one possible repair for
each constraint
18Attack / repair example
- Attack exploits the C implementation of a
Javascript system routine - The type of the Javascript argument is not
checked. - System routine casts to a C object, calls a
virtual method - The object has a virtual table entry that points
to injected code - Violated constraint is found at the method call
- JSRI Address is in a set of legal method
addresses - Possible repairs
- Ignore the call
- Call one of the known valid methods
- Return early
- No repair
19Evaluate repairs
- Server creates patches for each possible repair
for each correlated constraint - Server distributes each patch to a subset of the
community - When a patch is activated (the constraint is
violated), the community member evaluates it and
sends the results to the central server - Is the attack avoided?
- Does the program exhibit other problems?
- Central server analyzes results
- The most successful patch is distributed and
other patches are abandoned
20Conclusion
- Critical vulnerabilities are recognized
- Code injection
- Denial of service
- Framework can be extended to other detectors
- Vulnerability is closed (repaired)?
- This attack will fail in the future
- Overhead is low
- Detector overhead is low
- Only constraints associated with attacks are
logged - Effective on legacy x86 binaries