Shield: Vulnerability-Driven Network Filters for Preventing Known Vulnerability Exploits

1
Shield Vulnerability-Driven Network Filters for
Preventing Known Vulnerability Exploits

• Authors Helen J. Wang, Chuanxiong Guo, Daniel R.
  Simon, and Alf Zugenmaier
• Publication ACM SIGCOMM, 2004
• Presenter YanYan Wang

2
Motivation

• To defense software vulnerabilities between
  vulnerability disclosure and software patching.
• To propose a first-line worm defense in the
  network stack using shields to safely delay the
  needs for installing software patch that removes
  vulnerabilities.

3
Why It Is Necessary

• People do not patch their systems for following
  reasons
• Disruption
• Unreliability
• Irreversibility
• Unawareness

4
Shield Framework

• Vulnerability specific
• Exploit-generic
• installed at the end host
• Operates between application protocol layer and
  the transport layer
• Examines the incoming and outgoing traffic of
  vulnerable applications
• Corrects the traffic according to the
  vulnerability signature

5
Vulnerability Modeling

• A shield vulnerability signature describe the
  vulnerability state machine and how to recognize
  exploits in the vulnerable event.
• A shield policy specifies the vulnerability
  signature and actions needed to recognize an
  exploit. It is provided by the shield designers,
  mostly the application vulnerability vendor.

6
Vulnerability Modeling
Application Message
Pre-vulnerability State
7
Shield Architecture

• Goals for shield design
• Minimize the state maintained
• Need to resist resource consumption attacks (e.g.
  DoS).
• Enough flexibility to support any application
  level protocol
• Separate policy from mechanism
• Design fidelity
• Need to defend being an alternative target

8
Data Structure

• There are two main data structure
• The application vulnerability state machine
  specifications (Spec)
• Instruct shield to emulate the application
  vulnerability state machine at run time
• Contents state machines specifics, port number,
  event and session info.
• Run time session states
• Includes current state of the session and other
  context info.

9
Components

• Policy loader
• Integrate new shield policy with existing one or
  created new
• Application dispatcher
• Determine which Spec. to refer to upon arrival of
  raw data based on port number.
• Session dispatcher
• Obtain the location of the session ID, message.
  type, message. Boundary marker, and extract
  message(s), dispatch the event to appropriate
  state machine instance.

10
Components (cont.)

• State machine instance
• Give the new arrival event and the current state,
  consult with Spec., invoke the correspondent
  event handler and call shield interpret to decode
  the handler.
• Shield interpreter
• Find out how to parse application level protocol
  payload and examine for exploits from the
  handler, as well as drop packets, session
  tear-down, or setting the next state for current
  SMI.

11
Shield Architecture
12
Detailed Design Issue

• Scattered arrivals
• Recognize multi-data arrival
• Out-of-Order arrivals
• Shield copy and passes to the application
• Max needs to be set in the policy
• Application Level Fragmentation
• The Spec needs to contain the location of the
  application level fragment ID

13
Shield Policy Language
14
Shield Policy Language

• Payload specification - Static
• States, events, state machine transition, and
  generic application level protocol info.
• Loaded into Spec.
• Handler specification Run Time
• Handler specification and payload paring
  instructions
• Examine the packet payload, pinpoint any exploit,
  record the session context for later
• Syntax of the handlers and the payload format are
  parsed and stored in Spec. by policy loader

15
Implementation

• Shield Prototype Using WinSock2 LSP

• C
• Used vulnerability behind Slammer, MSBlast,
  CodeRed, and twelve other vulnerabilities from
  Microsoft security bulletins

16
Evaluation

• Applicability

17
Evaluation

• False Positives
• 36 cases for exhaustive testing SSRP protocol of
  SQL server 2000
• No false positive
• Does not mean false positive-free

18
Strength

• Defend vulnerability without installing patches
• Non-invasive
• Exploit-generic
• Development of shield policy language
• Set potential standard

19
Weakness

• Only work for known vulnerability
• Need to manually generate signatures
• Vulnerability specific
• Does not work on all vulnerability
• Bugs deeply embedded in the applications logic
• File-base vulnerability

20
Improvement

• Automated tool to generate signature
• More experiment on applications with
  vulnerability that does not apply to shield