Title: Shield: Vulnerability Driven Network Filters for Preventing Known Vulnerability Exploits
1Shield Vulnerability Driven Network Filters for
Preventing Known Vulnerability Exploits
- Authors Helen J. Wang, Chuanxiong Guo, Daniel R.
Simon, and Alf Zugenmaier - Published ACM SIGCOMM, 2004
- Presented By Anvita Priyam
2S/W patches
- A patch is a small piece of software designed to
update or fix problems with a computer program or
its supporting data. - Urgent security problem- threat of remote
attacks, based on vulnerabilities in currently
running S/W (specially worms) - Repair the vulnerability before it can be
exploited - S/W vendors develop distribute reparative
patches ASAP after learning of a vulnerability
3Overview
- Motivation for Shield
- Architecture
- Design Issues
- Analysis
- Evaluation
- Weaknesses
- Suggestions
4Motivation for Shield- Problems with patches
- Administrators do not often implement patches
immediately after they are made available - Reasons for failure to install
- gt Disruption- installing requires rebooting
- gt Unreliability- insufficient time to check
patches before they are released - gt Irreversibility- no easy way of uninstalling
- gt Unawareness- Administrator may miss it
5Shield
- First line worm defense in n/w stack, filters
traffic above transport layer - Vulnerability specific, exploit generic
- Installed in end systems before a patch is
applied
6GOALS
- There are three goals for Shield design
-
- gt Minimize limit the state maintained by
- Shield
-
- gt Enough flexibility to support any application
- level protocol
- gt Design fidelity
7Vulnerability Modeling
Embedded Application State Machine
S0
VULNERABILITY STATE MACHINE
S0
Message
S1
S2
S3
S4
S5
V4
S5
Exploit Event
V4
Protocol State Machine
8Vulnerability Modeling
- Each application is a finite state machine-
Application State Machine - Protocol State Machine- transitions are
application message arrivals - Vulnerability Signature- describes Vulnerability
State Machine how to exploits - Shield Policy- Vulnerability Signature actions
to take
9Shield Policy
- Specifies
- Application Identification- which packets are
destined for which application - Event Identification- how to extract message type
from a message - Session identification- which session a msg
belongs to - State Machine specification- states, machines,
transitions
10Shield Architecture
SessionID location MessageType Location
New Policies
PER APP SPEC
POLICY LOADER
Exe-gt Spec Id
HandlerAt(state,event)
How to parse msg identify a session
Event for session i
Raw Bytes Port
STATE MACHINE ENGINE
Raw bytes Spec ID
SESSION DISPATCHER
APPLICATION DISPATCHER
curState
Current State
Interpret(Handler)
ParsePayload
SHIELD INTERPRETER
SESSION STATE
Drop
TearDownSession
SetNextState
11Shield Modules
- Policy Loader integrates new policy with an
existing Spec ( or creates one) - Application Dispatcher forwards raw bytes and
spec to the session dispatcher - Session Dispatcher recognizes the event
session ID dispatches to corresponding state
machine instance (SMI) - SMI asks Spec which event handler to invoke,
calls the shield interpreter to interpret it
12Design Issues
- Scattered arrivals
- Out-of-Order Arrivals
- Application level Fragmentation
13Scattered arrivals
- Could be due to TCP congestion control or message
handling implementations of an application - Copy wait for rest of data to arrive
- Index copy-buffers for putting in place the later
arrivals - Pre-session copying/in-session copying
- Copy-buffer is de-allocated when complete message
is received.
14Out-of-Order Arrivals
- When application level protocol runs on top of
UDP, datagrams can arrive out of order - Copies datagrams passes to applications
- Sets the upper limit of the number of copied
datagrams to be maximum out of order datagrams
that application level protocol can handle
15Application Level Fragmentation
- Some application level protocols use application
data units perform fragmentation reassembly - Spec needs to contain the location of fragment ID
in the message - Ensures that the fragment is not treated as the
entire message event.
16Analysis
- Scalability with Number of Vulnerabilities
- gt number of shields should not grow very
large - gt state machines modeling vulnerabilities
should be merged into one - gt application throughput was halved at worst
- False Positives
- gt Should have very low false positives
- gt but may arise from incorrect policies
17EVALUATION
of vulnerabilities Nature Wormable Shieldable
6 Local No No
24 User-involved No Usually Hard
12 Server Buffer over runs Yes Easy
3 Cross site scripting No Hard
3 Server DOS No Varies
18Application Throughput
19Application Throughput
20WEAKNESSES
- Vulnerabilities from bugs embedded in
applications logic are hard to defend against - Simple vulnerabilities exploitable by malformed,
n/w protocol independent application objects are
difficult for shield to catch - Application encryption poses a problem for Shield
21Suggestions
- Applicability should be tested for more variety
of vulnerabilities - Testing shield should be made automated
- Applicability against virus problems should be
tested - Explore alternate deployment options other than
the end hosts