Collaborative%20learning%20for%20security%20and%20repair%20in%20application%20communities%20MIT%20

1
Collaborative 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
2
Application 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

3
Collaborative 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

4
The 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

5
Collaborative 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

6
Collaborative 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)?
7
Protection 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.

8
x lt 18
x lt 20
x lt 14
Merge Constraints
x lt 20
9
Security Server
10
Constraint/Attack Information
Constraint Information
Security Server
11
Constraint/Repair Information
Distribute possible repairs
Security Server
12
Patch Activation Information
Distribute most successful repair(s)?
Security Server
13
Learning

• 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

14
Monitoring 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

15
Memory 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
16
Memory 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

17
Logging - 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

18
Attack / 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

19
Evaluate 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

20
Conclusion

• 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