1. Shield: 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

2. S/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

3. Overview Motivation for Shield Architecture Design Issues Analysis
Evaluation
Weaknesses
Suggestions

4. Motivation for Shield- Problems with patches
Administrators do not often implement patches immediately after they are made available
Reasons for failure to install:
> Disruption- installing requires rebooting
> Unreliability- insufficient time to check patches before they are released
> Irreversibility- no easy way of uninstalling
> Unawareness- Administrator may miss it

5. Shield
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

6. GOALS There are three goals for Shield design:
> Minimize & limit the state maintained by
Shield
> Enough flexibility to support any application
level protocol
> Design fidelity

7. Vulnerability Modeling
Embedded
Application State Machine S0
VULNERABILITY
STATE MACHINE S0
Message S1 S2 S3 V4 S4 S5 S5
Exploit Event V4
Protocol State Machine

8. Vulnerability 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

9. Shield 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

10. Shield Architecture New Policies Raw Bytes Port# SessionID location
MessageType Location
New Policies
PER APP SPEC
POLICY
LOADER
Exe-> 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

11. Shield 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

12. Design Issues Scattered arrivals Out-of-Order Arrivals
Application level Fragmentation

13. Scattered 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.

14. Out-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

15. Application 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.

16. Analysis Scalability with Number of Vulnerabilities
> number of shields should not grow very large
> state machines modeling vulnerabilities should be merged into one
> application throughput was halved at worst
False Positives
> Should have very low false positives
> but may arise from incorrect policies

17. EVALUATION 6 24 Applicability of Shield Local No User-involved
#of vulnerabilities
Nature
Wormable
Shieldable 6
Local No 24
User-involved
Usually Hard 12
Server Buffer over runs
Yes
Easy 3
Cross site scripting
Hard
Server DOS
Varies

18. Application Throughput

19. Application Throughput

20. WEAKNESSES
Vulnerabilities from bugs embedded in application’s 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

21. Suggestions
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