Shield: VulnerabilityDriven Network Filters for Preventing Known Vulnerability Exploits

1
Shield Vulnerability-DrivenNetwork Filters for
PreventingKnown Vulnerability Exploits

• Helen J. Wang, Chuanxiong Guo,
• Daniel R. Simon, and Alf Zugenmaier
• Microsoft Research
• SIGCOMM 2004

2
Outline

• Introduction
• Vulnerability modeling and shield usage
• Shield archetecture
• Detailed design issues
• Shield policy language
• Analysis
• Implementation
• Evaluations
• Related work
• Conclusion and Further work

3
Introduction

• Security problems facing administrators of
  networked computer systems
• Attacks based on vulnerabilities
• Self-propagating attacks
• worms
• several reasons why administrators may fail to
  install software patches
• Disruption
• Unreliability
• Irreversibility
• Unawareness

4
Introduction

• Shield
• Intermediate "patch" in the network stack
• Vulnerability-specific, exploit-generic network
  filter
• End host , application layer
• Differs from previous anti-worm
• Remove a specific vulnerability directly before
  the vulnerability disclosure time

5
Vulnerability Modeling And Shield Usage

• Modeling and expressing vulnerability signatures
• Shield vulnerability signature
• Specifies all possible sequences of application
  message
• Specific payload characteristics

6
Vulnerability Modeling And Shield Usage
7
Vulnerability Modeling And Shield Usage

• Taxonomy for modeling vulnerability
• Each application -gt finite state machine
  (application state machine)
• Protocol state machine
• pre-vulnerability state
• the state in the protocol state machine at which
  receiving an exploitation network event could
  cause damage
• vulnerability state machine
• the partial protocol state machine that leads to
  the pre-vulnerability state
• vulnerable event
• the message that can potentially contain an
  exploit

8
Vulnerability Modeling And Shield Usage

• Shield
• Protect incoming traffic as firewall
• Outgoing traffic with application-specific
  knowledge

9
Shield ArchitectureGoals and Overview

• Three main goals for the shield design
• Minimize and limit the amount of state maintained
  by Shield
• Enough flexibility to support any application
  level protocol
• "Separating policy from mechanism"
• Shield's mechanism is generic, implementing
  operations common
• Shield policies specify the varying aspects of
  individual application level protocol design
• Design Fidelity
• not become an easier alternative attack target

10
Shield ArchitectureGoals and Overview

• Shield mechanisms the necessary generic
  elements of an application level protocol
• Application level protocols between two parties
  (say, a client and a server) are implemented
  using finite state automata
• application-level messages must indicate a
  message type and session ID
• out-of-order application datagrams
• message fragments
• The policy specifies the following
• Application identification
• Event identification
• Session identification (if applicable)
• State machine specification

11
Shield ArchitectureData Structure

• Per-app vulnerability state machine spec (Spec)
• Transformed from Shield policy
• Instructions for emulating vulnerability state
  machines in Shield at the runtime
• Application identification ports, dynamic port
  registration
• Vulnerability signature reactions states,
  events, handlers for recognizing and reacting to
  potential exploits
• Event and session identification
• Location (offset, size) vector of event type and
  session ID in the app message. Unit byte or
  WORD for text-based protocols
• Message boundaries, e.g., CRLF CRLF for HTTP and
  SMTP
• One state machine per application
• Multiple vulnerability state machines are merged
  into one
• Session State current state and session context
  for exploit-checking

12
Shield Architecture
13
Detailed Design Issuesscattered arrivals

• An application message is the smallest
  interpretable unit by the application
• Why scattered arrivals?
• Congestion control or application-specific
  message handling
• Copying save then pass on
• How to differentiate parsing state belonging to
  multiple sessions index copy-buffers
• Safe to use socket here because only one socket
  should be used for delivering a complete
  application level message
• Per-socket copying for incomplete message arrivals

14
Detailed Design Issuesscattered arrivals

• Pre-session copying before the session
  information arrives
• The parsing state is associated with the socket
  only
• In-session copying after the session information
  arrives
• The parsing state becomes part of the session
  state
• What to save (parsing state)
• the name of the current incomplete field
• the value of the current incomplete field only if
  the value is needed by Shield later
• Per application message

15
Detailed Design Issuesscattered arrivals

• For a vulnerable application
• Maintain the state of the current field being
  parsed each application messages
• Even determined not leading to any exploit
• Prevent ambiguity
• Other parts would treated as new application
  messages
• May cause inconsistencies by attacker

16
Detailed Design IssuesOut-of-Order Arrivals

• Copy out-of-order datagrams
• Upper limit of the number of copied datagrams
• The maximum that application-level protocol can
  handle
• Expressed in the policy descriptions as the
  sequence number location

17
Detailed Design IssuesApplication Level
Fragmentation

• some application-level protocols
• use application data units and perform
  application level fragmentation and re-assembly.
• Over TCP bytes are received in order
• Over UDP
• copies their out-of-order datagrams to retain the
  correct packet sequence
• no different from processing partially arrived
  data
• ordered copies of the fragments are treated the
  same as scattered arrivals
• Additional information needed in Shield policy
  fragment ID location

18
Shield Policy Language

• High specialized for Shields purpose
• Part 1
• Vulnerability state machine specification
• generic application level protocol info such as
  ports used, the locations of the event type,
  session ID, message boundary, etc.
• Part 2 Handler and payload parsing
  specifications for run-time interpretation

19
(No Transcript)
20
Shield Policy Language

• Payload specification
• Skippable fields of BYTES, WORDS, BOOL, or arrays
  of PAYLOAD_STRUCTs
• Handler specification
• Variable types BOOL, COUNTER, BYTES, WORDS
• Two scopes local or session
• Statements assignment, IF, special-purpose
  FOR-loop
• Coping with scattered arrivals
• handler continuation part of the session state
• consisting of statement ID queue, parsing state
• Stream-based built-in length functions or regular
  expression functionsscattered message arrivals
• e.g., COUNTER c MSG_LEN (legalLimit) c
  legalLimit 1 if msg exceeds stopCount number
  of bytes

21
(No Transcript)
22
(No Transcript)
23
AnalysisScalability with Number of
Vulnerabilities

• Scalability with Number of Vulnerabilities
• doesnt grow indefinitely upon successful
  patching, the corresponding shields are removed
• N shields for N apps ???1 shield
• Application-specific
• Multiple vulnerabilities of a single application
  can compound if they share paths on the
  vulnerability state machine
• not significant because no more than 3
  wormexploitable vulnerabilities seen in a single
  application in 2003
• Application throughput is at worst halved,
  traffic processed once in Shield and once in the
  application

24
Analysisfalse positive

• Low false positives by nature
• Two sources
• Misunderstanding of protocol and payload spec
  can be debugged with large traffic trace or test
  suites
• Differential treatment of a certain network
  event could be an exploit in one runtime
  setting, and yet completely legal in another

25
Implementation
26
EvaluationsApplicability of Shield

• Several potential geps
• Vulnerabilities that result from bugs in the
  applications logic are diffcult
• Network protocol-indepent application objects
  (like files) are difficult
• Vulnerability-specific anti-virus software
• Application-specific encryption

27
EvaluationsApplicability of Shield
28
EvaluationsApplication Throughput

• 1. Client -gt Server BIND
• 2. Server -gt Client BIND_ACK
• 3. Client -gt Server MSG_REQUEST
• 4. Server -gt Client MSG_RESPONSE of 1 MB data
• 5. Goto 1
• With 100Mbps or 1 Gbps switch

29
EvaluationsApplication Throughput
30
EvaluationsApplication Throughput
31
EvaluationsApplication Throughput
32
EvaluationsFalse Positives

• Evaluate on shield for Slammer.
• Used an SSRP stress test suite obtained from a MS
  test group 32 test cases for 12 message types
• No false positives observed.

33
Related Work

• Software defects
• Static checkerdata flow analysis
• Mitigation techniques
• Attack prevention techniques
• Patch and Shield
• Worm containment techniques
• Firewall
• Exploit signature-based Network Intrusion
  Prevention system (NIPS)
• Rate-limiting
• Network intrusion Detection Systems (NIDS)

34
Conclusion and Further Work

• Automated tool to ease Shield policy generation
• Not be implemented at the end host
• Automating testing make the shield release
  process easier
• Hacker reverse-engineering
• anti-virus system