Software Security Issues in Embedded Systems

1. Software Security Issues inEmbedded Systems Somesh Jha University of Wisconsin

2. Software Security Vulnerability Assessment Analysis tools for discovering vulnerabilities in source code and binaries Automated Signature Generation Generating signatures that filter our malicious inputs Malicious Code Detection Detecting whether a binary has malicious behavior

3. Embedded Systems Increasingly used in critical sectors Defense, medical, power, … Malicious and accidental failures can have dire consequences Embedded systems are not “all hardware” They have software too? Autonomous nature

4. Dynamic and Configurable Environment Embedded systems are highly configurable They have to work in many different scenarios Environment is highly dynamic Think about embedded systems in a battlefield Embedded system in a vehicle

5. Changing Functional Requirements Functional requirements of embedded systems change over time Embedded system deployed in a battlefield Functional requirements change with mission

6. Interconnected Network of Components Embedded system are of a complex network of components Components might be hardware or software Source code might be available for some components COTS components (only binary available) Failure can create cascading events

7. Recovery is Paramount Embedded systems used in critical applications In some cases recovery is paramount Recovery complicated by complex interaction of events Failure can cause a complex cascade of events

8. Three Software Security Projects Automated generation of vulnerability signatures Retrofitting legacy code Static analysis of binaries Malware Detection

12. Goals for Automatic Signature Generation Create signature that matches exploits Reason about signature accuracy Does it match legitimate traffic (false +)? Does it miss exploits (false -)?

13. Our Contribution: A Language-Centric Approach

14. Language of a Particular Vulnerability A vulnerability is defined by: What – The Vulnerability Condition: Necessary conditions to violate safety Where – The Vulnerability Point: Location vulnerability condition first satisfied Both are available from exploit detectorsBoth are available from exploit detectors

15. HTTP-like Running Example int check_http(char input[9]) { if(strcmp(input, “get”,3) != 0 || strcmp(input, “head”,4) != 0) return -1; if(input[4] != ‘/‘) return -1; int I = 5; while(input[I] != ‘\n‘){ I++; } input[I] = 0; return I; }

16. Example Input: get_/aaaa\n

17. Example Input: get_/aaaa\n

18. Retrofitting legacy code Legacy code won’t go away, and their security problems won’t go away. We need systematic techniques to retrofit legacy code with security mechanisms.Legacy code won’t go away, and their security problems won’t go away. We need systematic techniques to retrofit legacy code with security mechanisms.

19. Retrofitting legacy code Enforcing type safety CCured [Necula et al. ’02] Partitioning for privilege separation PrivTrans [Brumley and Song, ’04] Enforcing authorization policies

20. Enforcing authorization policies We would like to enhance the resource manager so that it checks the authorization policy before granting the resource request. This is achieved by consulting an authorization policy. The mechanism used to achieve this is called a reference monitor. Give examples of real resource users and resource managers here. For example, the operating system is a resource manager, and processes are resources. A server is a resource manager and its clients are resource users.We would like to enhance the resource manager so that it checks the authorization policy before granting the resource request. This is achieved by consulting an authorization policy. The mechanism used to achieve this is called a reference monitor. Give examples of real resource users and resource managers here. For example, the operating system is a resource manager, and processes are resources. A server is a resource manager and its clients are resource users.

21. Retrofitting for authorization Mandatory access control for Linux Linux Security Modules [Wright et al.,’02] SELinux [Loscocco and Smalley,’01] Secure windowing systems Trusted X, Compartmented-mode workstation, X11/SELinux [Epstein et al.,’90][Berger et al.,’90][Kilpatrick et al.,’03] Java Virtual Machine/SELinux [Fletcher,‘06] IBM Websphere/SELinux [Hocking et al.,‘06] There are now several efforts to integrate authorization policy enforcement, not only into operating systems, but also into general purpose applcaitons. The integration of mandatory access control in Linux has spurred the integration of authorization policy enforcement frameworks in applications as well.There are now several efforts to integrate authorization policy enforcement, not only into operating systems, but also into general purpose applcaitons. The integration of mandatory access control in Linux has spurred the integration of authorization policy enforcement frameworks in applications as well.

22. Retrofitting lifecycle Identify security-sensitive operations Locate where they are performed in code Instrument these locations What are security-sensitive operations? These are fundamental operations on resources, in this case Window resource, that we would like to mediate access to. That is, when an X client requests that these operations be performed on a Window, we would like to consult an authorization policy to check that this request can be allowed. Mention that the state of the art is manual.What are security-sensitive operations? These are fundamental operations on resources, in this case Window resource, that we would like to mediate access to. That is, when an X client requests that these operations be performed on a Window, we would like to consult an authorization policy to check that this request can be allowed. Mention that the state of the art is manual.

23. Problems Time-consuming X11/SELinux ~ 2 years [Kilpatrick et al., ‘03] Linux Security Modules ~ 2 years [Wright et al., ‘02] Error-prone [Zhang et al., ‘02][Jaeger et al., ‘04] Violation of complete mediation Time-of-check to Time-of-use bugs Say that these points make it clear that we need automated techniques to retrofit legacy codeSay that these points make it clear that we need automated techniques to retrofit legacy code

24. Our approach Retrofitting takes just a few hours Automatic analysis: ~ minutes Interpreting results: ~ hours Basis to prove security of retrofitted code Emphasize the impact of your approach: mention that you applied it to real code and your experimental results demonstrate that manual effort is drastically reduced and that it provides a basis to prove security. Mention also that the net result of your approach is that we can now secure more legacy code faster. Emphasize the impact of your approach: mention that you applied it to real code and your experimental results demonstrate that manual effort is drastically reduced and that it provides a basis to prove security. Mention also that the net result of your approach is that we can now secure more legacy code faster.

25. Malspec: Self-Propagation by Email These operations need to be constrained such that they specify only the malicious behavior. For this purpose we use semantic constraints between operations. In this example, the constraint for write says that its first argument should be the same socket as the one used by connect and the second argument should contain the “EHLO” command of the mail transfer protocol. I initially built these malspecs through manual analysis. Later on, I developed an automatic technique for mining malspecs from a known piece of malware. These operations need to be constrained such that they specify only the malicious behavior. For this purpose we use semantic constraints between operations. In this example, the constraint for write says that its first argument should be the same socket as the one used by connect and the second argument should contain the “EHLO” command of the mail transfer protocol. I initially built these malspecs through manual analysis. Later on, I developed an automatic technique for mining malspecs from a known piece of malware.

26. Building a Real Malspec A complete malspec is certainly larger. Email propagation has two high-level actions: the malware has to read the contents of its executable file and then it has to send email. I can express these high-level actions as sequence of program operations. But many email programs exhibit this same behavior. They load icons from their executable file and they send email. This malspec is imprecise. To make it more precise, we need to connect the two high-level actions. The contents of the executable file has to send over the network.A complete malspec is certainly larger. Email propagation has two high-level actions: the malware has to read the contents of its executable file and then it has to send email. I can express these high-level actions as sequence of program operations. But many email programs exhibit this same behavior. They load icons from their executable file and they send email. This malspec is imprecise. To make it more precise, we need to connect the two high-level actions. The contents of the executable file has to send over the network.

27. Malspec: Self-Propagation by Email Here is the malspec for a mass-mailing worm. A malspec is a graph (formally an AND-OR graph) where edges are program operations and constraints on those operations. This representation has several interesting features. A malspec, formally, is an AND-OR graph, where AND edges model requirements while OR edges model alternate sequences of operations.Here is the malspec for a mass-mailing worm. A malspec is a graph (formally an AND-OR graph) where edges are program operations and constraints on those operations. This representation has several interesting features. A malspec, formally, is an AND-OR graph, where AND edges model requirements while OR edges model alternate sequences of operations.

28. Malspec Constraints First, constraints are embedded in the graph. There are local constraints, such as this one, which requires that the second argument of the write is the EHLO command in the SMTP protocol. There are dependence constraints that relate arguments of different operations. A simple dependence constraint, through the symbolic variable X, says that the value output by the socket call is the value used by the connect call. A more complex dependence constraint says that the buffer T, sent to the network in the last operation of the malspec, is a Base64-encoding of the buffer Y read from the file.First, constraints are embedded in the graph. There are local constraints, such as this one, which requires that the second argument of the write is the EHLO command in the SMTP protocol. There are dependence constraints that relate arguments of different operations. A simple dependence constraint, through the symbolic variable X, says that the value output by the socket call is the value used by the connect call. A more complex dependence constraint says that the buffer T, sent to the network in the last operation of the malspec, is a Base64-encoding of the buffer Y read from the file.

29. Malspecs Benefits Representing malicious behavior as a graph of symbolic operations and their constraints gives us several desirable features. First, symbolic variables make the malspec independent of particular memory and register usage patterns. Second, the graph structure connects only operations that are related through a constraint. For example, open and connect are not related in any way, and can execute in any order. Third, because the operations in the graph are strictly necessary to achieve the malicious goal, the attacker has no opportunities for obfuscation.Representing malicious behavior as a graph of symbolic operations and their constraints gives us several desirable features. First, symbolic variables make the malspec independent of particular memory and register usage patterns. Second, the graph structure connects only operations that are related through a constraint. For example, open and connect are not related in any way, and can execute in any order. Third, because the operations in the graph are strictly necessary to achieve the malicious goal, the attacker has no opportunities for obfuscation.

30. Malspec Detection Strategies Static analysis Dynamic analysis Host-based IDS Inline Reference Monitors When it comes to detection, there are multiple ways to determine whether behavior specified by a malspec appears in a program. Because the malspec is independent of the detection approach, one can use static analysis, or dynamic analysis, or a host-based IDS, or inline reference monitors. My research focuses on detection based on static analysis, which I will present today. As part of ongoing work at Wisconsin, we are also implementing a dynamic detection technique.When it comes to detection, there are multiple ways to determine whether behavior specified by a malspec appears in a program. Because the malspec is independent of the detection approach, one can use static analysis, or dynamic analysis, or a host-based IDS, or inline reference monitors. My research focuses on detection based on static analysis, which I will present today. As part of ongoing work at Wisconsin, we are also implementing a dynamic detection technique.

31. Detection of Malicious Behavior One option is to do byte-signature matching over instructions that represent the corresponding malspec operations. This option ignores the constraints and is as limited as standard byte signatures.One option is to do byte-signature matching over instructions that represent the corresponding malspec operations. This option ignores the constraints and is as limited as standard byte signatures.

32. Find A Malicious Program Path One option is to do byte-signature matching over instructions that represent the corresponding malspec operations. This option ignores the constraints and is as limited as standard byte signatures.One option is to do byte-signature matching over instructions that represent the corresponding malspec operations. This option ignores the constraints and is as limited as standard byte signatures.

33. Stable Environment Assumption All the above mentioned work assumes a “nearly” stable environment Example: web server Is configurable, but the environment is not that rich Environment is not too dynamic Not rich interaction with other components Incorporating “dynamic environments” into the techniques described before is a challenge

34. Vulnerability Assessment in Presence of a Dynamic Environment Dynamic and static analysis techniques assume a relatively stable environment Parameterized static analysis Parameterize static analysis with environment assumptions Similar to assume-guarantee reasoning in model checking Parameterized vulnerability signatures

35. Recovery from Failures A failure (malicious or benign) can cause a complex cascade of events Need to understand the complex cascade of events caused by a failure Need to analyze the complex network in components in totality Scalability Compositional analysis

36. Questions My web page http://www.cs.wisc.edu/~jha