Shield: Vulnerability-Driven Network Filters for Preventing Known Vulnerability Exploits
-
Upload
asher-rose -
Category
Documents
-
view
33 -
download
2
description
Transcript of Shield: Vulnerability-Driven Network Filters for Preventing Known Vulnerability Exploits
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
won’t 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 program’s 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
11
Objectives for Shield design1. Minimize and limit the amount of state
maintained by Shield– Shield must resist any resource consumption
attacks as well as the program it shields
2. Enough flexibility to support any application level protocol
3. Design fidelity– Shield should not be an easier target than the
program it protects
Shield Architecture
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
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… >>payload tells Shield to parse and to
refer to the bytes that represent the “payload” of the packet
23
Shield for vulnerability behind CodeRedSHIELD(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,BYTES(REST) dummy2,
} P_Get_Request;
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 (>>P_Get_Request.URI, "\?(.*)$", legalLimit);
IF (c > legalLimit)# Exploit!TEARDOWN_SESSION;RETURN (S_FINAL);FIRETURN (S_FINAL);
};
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
S1 S2
S3
V6S5
V4
27
Scalability With vulnerabilities
that share paths, overhead may be cumulative Not many of these
vulnerabilities
S1
S3S2
V5
S4
V6
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
application’s 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 don’t involve protocol messages?