1. 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. 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. 3 Outline  Why?  How? Details  Scalability  Implementation  Analysis of Paper

4. 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. 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. 6 Outline  Why?  How? Details  Scalability  Implementation  Analysis of Paper

7. 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. 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. 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. 10

11. 11  Objectives for Shield design 1.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. 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. 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. 14 Shield Architecture  Data Structures Specs Session states  Policy Loader transforms policies into Specs

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

19. 19 Design Issues  Out-of-Order Arrivals  Scattered Arrivals  Application-Level Fragmentation

20. 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. 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. 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. 23 Shield for vulnerability behind CodeRed SHIELD(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); FI RETURN (S_FINAL); };

24. 24 Outline  Why?  How? Details  Scalability  Implementation  Analysis of Paper

25. 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. 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

27. 27 Scalability  With vulnerabilities that share paths, overhead may be cumulative Not many of these vulnerabilities

28. 28 Outline  Why?  How? Details  Scalability  Implementation  Analysis of Paper

29. 29 Implementation  WinSock2 Layered Service Provider  Compiled into a DLL  10,702 lines of C++

30. 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. 31 Vulnerabilities of MSRC over the year 2003 # of Vuln. NatureWormableShieldable 6LocalNo 24User-involvedNoUsually hard 12Server buffer overruns YesEasy 3Cross-site scripting NoHard 3Server Denial- of-service NoVaries

32. 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. 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. 34 CPU Comparison for 100 Mbps Switch

35. 35 Throughput Comparison for 1 Gbps Switch

36. 36 Outline  Why?  How? Details  Scalability  Implementation  Analysis of Paper

37. 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. 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. 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?