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

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

• By Helen J. Wang, Chuanxiong Guo, Daniel R.
  Simon, and Alf Zugenmaier
• Presented at ACM SIGCOMM 2004

Presented by Jared Bott
2
What is Shield?

• Program that patches vulnerabilities in
  applications
• Blocks network traffic from exploiting the
  vulnerabilities
• Only deals with network traffic, so it wont
  cause side effects like patches
• Operates on vulnerabilities, not exploits

3
Outline

• Why?
• How?
• Details
• Scalability
• Implementation
• Analysis of Paper

4
Why do we need Shield?

• Patches have many issues
• Disruption
• Often times, patches require stopping a
  program/service or rebooting a machine
• Unreliability
• Patches often have side effects due to a focus on
  speed (getting the patch out), so little testing
  is done
• Often other updates are bundled in with security
  updates

5
Why do we need Shield?

• Irreversibility
• Most patches cannot be easily uninstalled if
  something does not work correctly
• Unawareness
• Administrators may be unaware of a new patch or
  fail to act upon it
• Shield aims to alleviate these problems

6
Outline

• Why?
• How?
• Details
• Scalability
• Implementation
• Analysis of Paper

7
How does Shield work?

• The producer of an application details the states
  of their program and the protocol(s) used by the
  program
• Shield policy details vulnerability signature and
  the actions to take on recognizing an exploit
• For each session between the program and another
  computer, Shield has an instance of the programs
  state machine so that Shield can prevent any
  traffic that will cause an exploit

8
Vulnerability Modeling

• When a new vulnerability is discovered a Shield
  designer creates a Shield policy for the
  vulnerability
• Shield Vulnerability Signature Specifies all
  sequences of application messages and payload
  characteristics that lead to a remote exploit of
  a vulnerability
• Each application can be considered as a finite
  state machine, called the Application State
  Machine

9
Vulnerability Modeling

• Protocol State Machine
• State machine that describes the state of program
  in relation to the arrival of protocol messages
• Each state in the PSM overlays a set of states
  from the ASM
• Smaller and simpler than the ASM
• Pre-Vulnerability State The state in the PSM at
  which receiving an exploitation network event
  could cause damage

10
(No Transcript)
11
Shield Architecture

• Objectives for Shield design
• Minimize and limit the amount of state maintained
  by Shield
• Shield must resist any resource consumption
  attacks as well as the program it shields
• Enough flexibility to support any application
  level protocol
• Design fidelity
• Shield should not be an easier target than the
  program it protects

12
Shield Architecture

• Shield separates policy from mechanism
• Sessions must be identified
• Application-level protocols must provide a
  message type and Session ID
• Out-of-order messages and application-level
  protocol message fragments must be handled

13
Shield Architecture

• Policies must specify
• How to identify an application
• How to extract message type for event
  identification
• How to determine the session associated with a
  message
• States, events and transitions defining the PSM

14
Shield Architecture

• Data Structures
• Specs
• Session states
• Policy Loader transforms policies into Specs

15
Modules

• Policy Loader Integrates new/modified policies
  into existing Spec or creates new Spec Syntax
  parsing
• Application Dispatcher Determines which Spec to
  reference when raw bytes arrive
• Forwards data (bytes) and Spec to Session
  Dispatcher

16
Modules

• Session Dispatcher Figures out locations of
  Session ID, message type and message boundary
  marker
• Sends event to the corresponding State Machine
  Instance
• State Machine Instance
• Given a newly arrived event and the current
  state, the SMI consults the Spec about which
  event handler to invoke
• Calls the Shield Interpreter to interpret the
  event handler
• One SMI per session

17
Modules

• Shield Interpreter Interprets the event handler
• Event handler specifies how to parse the
  application-level protocol payload and examine it
  for exploits
• Carries out packet-dropping, session tear-down,
  registering a newly-negotiated dynamic port with
  Shield, setting the next state for the current SMI

18
(No Transcript)
19
Design Issues

• Out-of-Order Arrivals
• Scattered Arrivals
• Application-Level Fragmentation

20
Policy Language

• Describes states, events, transitions, generic
  ALP information
• Loaded into Spec data structure by the Policy
  Loader
• Describes handler specification and payload
  parsing instructions
• Handlers examine the packet payload and pinpoint
  any exploit in the current packet payload
• Record the session context that is needed for a
  later determination of exploit occurrence

21
Policy Language

• Payload Specification
• Example
• PAYLOAD_STRUCT
• SKIP BYTES(6) dummy1,
• BYTES(1) numTransferContexts,
• SKIP BYTES(1) dummy2,
• BYTES(16) UUID_RemoteActivation,
• SKIP BYTES(4) version,
• SKIP BYTES(numTransferContexts 20)
  transferContexts,
• P_Context

22
Policy Language

• Handler Specification
• 4 Data Types BOOL, COUNTER, BYTES, WORD
• Built-in functions DROP, TEARDOWN_SESSION,
  REGISTER_PORT
• gtgtpayload tells Shield to parse and to refer to
  the bytes that represent the payload of the
  packet

23
Shield for vulnerability behind CodeRed

• HANDLER H_Get_Request (P_Get_Request)
• COUNTER legalLimit 239
• COUNTER c 0
• \?(.) is the regular expression to retrieve
  the
• query string in the URI
• MATCH_STR_LEN returns legalLimit 1 when
  legalLimit is exceeded
• c MATCH_STR_LEN (gtgtP_Get_Request.URI,
  "\?(.)", legalLimit)
• IF (c gt legalLimit)
• Exploit!
• TEARDOWN_SESSION
• RETURN (S_FINAL)
• FI
• RETURN (S_FINAL)

• SHIELD(Vulnerability_Behind_CodeRed, TCP, (80))
• INITIAL_STATE S_WaitForGetRequest
• FINAL_STATE S_Final
• MSG_TYPE_LOCATION (0, 1) WORD
• MSG_BOUNDARY "\r\n\r\n"
• EVENT E_GET_REQUEST ("GET", INCOMING)
• STATE_MACHINE
• (S_WaitForGetRequest, E_GET_Request,
  H_Get_Request),
• PAYLOAD_STRUCT
• WORDS(1) method,
• WORDS(1) URI,

24
Outline

• Why?
• How?
• Details
• Scalability
• Implementation
• Analysis of Paper

25
Scalability

• Remove a shield after the vulnerability it covers
  is patched
• N Shields for N different applications are
  equivalent to a single shield in terms of their
  effect on the performance of any single
  application

26
Scalability

• When multiple vulnerabilities on one application
  appear on disjoint paths of their state machine,
  per-packet shield processing overhead for them is
  almost equivalent to the overhead for one
  vulnerability

27
Scalability

• With vulnerabilities that share paths, overhead
  may be cumulative
• Not many of these vulnerabilities

28
Outline

• Why?
• How?
• Details
• Scalability
• Implementation
• Analysis of Paper

29
Implementation

• WinSock2 Layered Service Provider
• Compiled into a DLL
• 10,702 lines of C

30
Vulnerabilities

• Modeled vulnerabilities behind Slammer, MSBlast,
  CodeRed and twelve other vulnerabilities
• All were input validation failure vulnerabilities
  (i.e. buffer overflow, integer overflow)
• Can Shield deal with common vulnerabilities?

31
Vulnerabilities ofMSRC over the year 2003
of Vuln. Nature Wormable Shieldable
6 Local No No
24 User-involved No Usually hard
12 Server buffer overruns Yes Easy
3 Cross-site scripting No Hard
3 Server Denial-of-service No Varies
32
Vulnerabilities

• Shield is not good for
• Bugs that are deeply embedded in an applications
  logic
• Exploits using files
• Messages that are encrypted by the application

33
Application Throughput

• Dell PWS650 Server w/3.06 GHz CPU and 1 GB RAM
• Clients connect using 100 Mbps and 1 Gbps
  Ethernet connections
• Clients send 1 MB messages using TCP
• Performance would increase if not a WinSock LSP

34
CPU Comparison for 100 Mbps Switch
35
Throughput Comparison for 1 Gbps Switch
36
Outline

• Why?
• How?
• Details
• Scalability
• Implementation
• Analysis of Paper

37
Strengths

• Shield provides a solution that is reliable,
  minimally disruptive, reversible and can be
  safely automatically updated
• Provides a safe, compact policy/protocol design
  language

38
Weaknesses

• Implementation has performance issues
• False positives can occur from a misunderstanding
  of the PSM
• Specs give attackers an easy way to understand
  vulnerabilities

39
Further Research

• Automated tools for Shield policy generation
• Implement Shield at some place other than the end
  host
• Distribution of shields
• Can this be applied to vulnerabilities that dont
  involve protocol messages?