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

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

Overview Motivation for Shield Architecture Design Issues Analysis Evaluation Weaknesses Suggestions

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

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

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

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

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

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

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

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

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

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.

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

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.

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

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

Application Throughput

Application Throughput

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

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