Title: Shield: VulnerabilityDriven Network Filters for Preventing Known Vulnerability Exploits
1Shield Vulnerability-DrivenNetwork Filters for
PreventingKnown Vulnerability Exploits
- Helen J. Wang, Chuanxiong Guo,
- Daniel R. Simon, and Alf Zugenmaier
- Microsoft Research
- SIGCOMM 2004
2Outline
- Introduction
- Vulnerability modeling and shield usage
- Shield archetecture
- Detailed design issues
- Shield policy language
- Analysis
- Implementation
- Evaluations
- Related work
- Conclusion and Further work
3Introduction
- Security problems facing administrators of
networked computer systems - Attacks based on vulnerabilities
- Self-propagating attacks
- worms
- several reasons why administrators may fail to
install software patches - Disruption
- Unreliability
- Irreversibility
- Unawareness
4Introduction
- Shield
- Intermediate "patch" in the network stack
- Vulnerability-specific, exploit-generic network
filter - End host , application layer
- Differs from previous anti-worm
- Remove a specific vulnerability directly before
the vulnerability disclosure time
5Vulnerability Modeling And Shield Usage
- Modeling and expressing vulnerability signatures
- Shield vulnerability signature
- Specifies all possible sequences of application
message - Specific payload characteristics
6Vulnerability Modeling And Shield Usage
7Vulnerability Modeling And Shield Usage
- Taxonomy for modeling vulnerability
- Each application -gt finite state machine
(application state machine) - Protocol state machine
- pre-vulnerability state
- the state in the protocol state machine at which
receiving an exploitation network event could
cause damage - vulnerability state machine
- the partial protocol state machine that leads to
the pre-vulnerability state - vulnerable event
- the message that can potentially contain an
exploit
8Vulnerability Modeling And Shield Usage
- Shield
- Protect incoming traffic as firewall
- Outgoing traffic with application-specific
knowledge
9Shield ArchitectureGoals and Overview
- Three main goals for the shield design
- Minimize and limit the amount of state maintained
by Shield - Enough flexibility to support any application
level protocol - "Separating policy from mechanism"
- Shield's mechanism is generic, implementing
operations common - Shield policies specify the varying aspects of
individual application level protocol design - Design Fidelity
- not become an easier alternative attack target
10Shield ArchitectureGoals and Overview
- Shield mechanisms the necessary generic
elements of an application level protocol - Application level protocols between two parties
(say, a client and a server) are implemented
using finite state automata - application-level messages must indicate a
message type and session ID - out-of-order application datagrams
- message fragments
- The policy specifies the following
- Application identification
- Event identification
- Session identification (if applicable)
- State machine specification
11Shield ArchitectureData Structure
- Per-app vulnerability state machine spec (Spec)
- Transformed from Shield policy
- Instructions for emulating vulnerability state
machines in Shield at the runtime - Application identification ports, dynamic port
registration - Vulnerability signature reactions states,
events, handlers for recognizing and reacting to
potential exploits - Event and session identification
- Location (offset, size) vector of event type and
session ID in the app message. Unit byte or
WORD for text-based protocols - Message boundaries, e.g., CRLF CRLF for HTTP and
SMTP - One state machine per application
- Multiple vulnerability state machines are merged
into one - Session State current state and session context
for exploit-checking
12Shield Architecture
13Detailed Design Issuesscattered arrivals
- An application message is the smallest
interpretable unit by the application - Why scattered arrivals?
- Congestion control or application-specific
message handling - Copying save then pass on
- How to differentiate parsing state belonging to
multiple sessions index copy-buffers - Safe to use socket here because only one socket
should be used for delivering a complete
application level message - Per-socket copying for incomplete message arrivals
14Detailed Design Issuesscattered arrivals
- Pre-session copying before the session
information arrives - The parsing state is associated with the socket
only - In-session copying after the session information
arrives - The parsing state becomes part of the session
state - What to save (parsing state)
- the name of the current incomplete field
- the value of the current incomplete field only if
the value is needed by Shield later - Per application message
15Detailed Design Issuesscattered arrivals
- For a vulnerable application
- Maintain the state of the current field being
parsed each application messages - Even determined not leading to any exploit
- Prevent ambiguity
- Other parts would treated as new application
messages - May cause inconsistencies by attacker
16Detailed Design IssuesOut-of-Order Arrivals
- Copy out-of-order datagrams
- Upper limit of the number of copied datagrams
- The maximum that application-level protocol can
handle - Expressed in the policy descriptions as the
sequence number location
17Detailed Design IssuesApplication Level
Fragmentation
- some application-level protocols
- use application data units and perform
application level fragmentation and re-assembly. - Over TCP bytes are received in order
- Over UDP
- copies their out-of-order datagrams to retain the
correct packet sequence - no different from processing partially arrived
data - ordered copies of the fragments are treated the
same as scattered arrivals - Additional information needed in Shield policy
fragment ID location
18Shield Policy Language
- High specialized for Shields purpose
- Part 1
- Vulnerability state machine specification
- generic application level protocol info such as
ports used, the locations of the event type,
session ID, message boundary, etc. - Part 2 Handler and payload parsing
specifications for run-time interpretation
19(No Transcript)
20Shield Policy Language
- Payload specification
- Skippable fields of BYTES, WORDS, BOOL, or arrays
of PAYLOAD_STRUCTs - Handler specification
- Variable types BOOL, COUNTER, BYTES, WORDS
- Two scopes local or session
- Statements assignment, IF, special-purpose
FOR-loop - Coping with scattered arrivals
- handler continuation part of the session state
- consisting of statement ID queue, parsing state
- Stream-based built-in length functions or regular
expression functionsscattered message arrivals - e.g., COUNTER c MSG_LEN (legalLimit) c
legalLimit 1 if msg exceeds stopCount number
of bytes
21(No Transcript)
22(No Transcript)
23AnalysisScalability with Number of
Vulnerabilities
- Scalability with Number of Vulnerabilities
- doesnt grow indefinitely upon successful
patching, the corresponding shields are removed - N shields for N apps ???1 shield
- Application-specific
- Multiple vulnerabilities of a single application
can compound if they share paths on the
vulnerability state machine - not significant because no more than 3
wormexploitable vulnerabilities seen in a single
application in 2003 - Application throughput is at worst halved,
traffic processed once in Shield and once in the
application
24Analysisfalse positive
- Low false positives by nature
- Two sources
- Misunderstanding of protocol and payload spec
can be debugged with large traffic trace or test
suites - Differential treatment of a certain network
event could be an exploit in one runtime
setting, and yet completely legal in another
25Implementation
26EvaluationsApplicability of Shield
- Several potential geps
- Vulnerabilities that result from bugs in the
applications logic are diffcult - Network protocol-indepent application objects
(like files) are difficult - Vulnerability-specific anti-virus software
- Application-specific encryption
27EvaluationsApplicability of Shield
28EvaluationsApplication Throughput
- 1. Client -gt Server BIND
- 2. Server -gt Client BIND_ACK
- 3. Client -gt Server MSG_REQUEST
- 4. Server -gt Client MSG_RESPONSE of 1 MB data
- 5. Goto 1
- With 100Mbps or 1 Gbps switch
29EvaluationsApplication Throughput
30EvaluationsApplication Throughput
31EvaluationsApplication Throughput
32EvaluationsFalse Positives
- Evaluate on shield for Slammer.
- Used an SSRP stress test suite obtained from a MS
test group 32 test cases for 12 message types - No false positives observed.
33Related Work
- Software defects
- Static checkerdata flow analysis
- Mitigation techniques
- Attack prevention techniques
- Patch and Shield
- Worm containment techniques
- Firewall
- Exploit signature-based Network Intrusion
Prevention system (NIPS) - Rate-limiting
- Network intrusion Detection Systems (NIDS)
34Conclusion and Further Work
- Automated tool to ease Shield policy generation
- Not be implemented at the end host
- Automating testing make the shield release
process easier - Hacker reverse-engineering
- anti-virus system