A Passive-based method to detect vulnerabilities

1. A Passive-based method to detect vulnerabilities Amel Mammar, Ana Cavalli, Edgardo Montes de Oca Shanai Ardi, David Byers, Nahid Shahmehri Presented by Willy Jimenez, Telecom Sudparis The research leading to these results has received funding from the European Community’s Seventh Framework Programme (FP7/2007-2013) under grant agreement n° 215995.

2. Objectives • This work is part of our contribution to the European Project Shield • http://www.shieldsproject.eu/ • Our main goal • To automatize vulnerability detection • To define a method for vulnerability detection based on our previous work on passive testing • To exploit our experience on the application of passive testing techniques to communication protocols • To adapt our tool in order to detect vulnerabilities on a piece of code (in particular for C program language)

3. Plan • Introduction • State of the art • A graphical formalism for vulnerabilities VCG • A Formal language for vulnerabilities VDC • From VCG to VDC • New approach for vulnerability detection • Conclusion

4. Introduction • A Software Vulnerability can be seen as a flaw, weakness or even an error in the system that can be exploited by an attacker in order to alter the normal behavior of the system

5. Introduction • BUFFER OVERFLOWS: it occurs usually with fixed length buffers when some data is going to be written beyond the boundaries of the current defined capacity • CROSS SITE SCRIPTING: consists in the injection of code in the pages accessed by other users • SQL INJECTION: consists in the injection of code with the intension of exploiting the content of a database • FORMAT STRING BUGS: it happens when external data is given to an output function as format string argument • INTEGER OVERFLOWS: can be of two different types, sign conversion bugs and arithmetic overflows.

6. State of the art • Vulnerability detector is an automated tool that helps developers to find vulnerabilities in software being developed • They can be static or dynamic • Limitation of existing tools • Existing tools are usually very focused on specific types of vulnerabilities • They have a high degree of false positives as false negatives • It is impossible for users of these tools to know which vulnerabilities any given tool actually deals with • There are no methods for improving the tools as new threats and risks are discovered

7. Vulnerability Cause Graphs (1) • A Vulnerability Cause Graph (VCG) is • a directed acyclic graph that contains an exit node representing the vulnerability being modelled • and cause nodes that represent conditions and events during software development process that might result in the vulnerability • Cause nodes are of four kinds: simple nodes, compound nodes and conjunction nodes • The edges in the VCG represent relathionships (not necessarily causal relationhips) between causes and the vulnerability

8. Vulnerability Cause Graphs (2) This VCG models a CVE-2005-3192 Vulnerability (a remote buffer overflow in xpdf viewer)

9. Vulnerability Cause Graphs (3) • VCGs were developed to determine how to prevent a vulnerability: to prevent a vulnerability, all the predecessors of the exit node must be prevented • Limitations • Although the structure of VCGs is formal, causes lacks of a formally defined semantics • To use VCGs to automatize vulnerabilities detection it is necessary to provide them with a formal semantics

10. Formal representation of vulnerabilities • We propose to provide a formal representation of vulnerabilities, using the concept of Vulnerability detection condition • The main idea of this concept is to point out the use of a dangerous action under some particular conditions. For example, it is dangerous to use a memory variable if it is not allocated yet.

11. Formal representation of vulnerabilities • Vulnerability detection condition: Let Act be a set of action names, Var be a set of variables, and P be a set of predicates on (VarAct). We say that Vdc is a vulnerability detection condition if Vdc is of the form: Vdc ::= a/P(Var, Act) | a[/P(Var, Act)]; P’(Var, Act) where a denotes an action, P(Var, Act) and P’(Var, Act) represent any predicates on variables Var and actions Act. A vulnerability detection condition a/P(Var, Act) means that action a occurs when specific conditions denoted by predicate P(Var, Act) hold. Similarly, a vulnerability detection condition a[/P(Var, Act)];P’(Var, Act)) means that action a used under the optional conditions P(Var, Act) is not followed by a statement whose execution satisfies P’(Var, Act).

12. Formal representation of vulnerabilities • If Vdc1 and Vdc2 are vulnerability detection conditions, then (Vdc1Vdc2) and (Vdc1Vdc2) are vulnerability detection conditions too.

13. Examples • Vulnerability detection condition Vdc1 permits to detect the referencing of a free or not allocated memory. • Assign(x, y) denotes the assignment of value y to the memory variable x: Vdc1 = Assign(x,y)/IsNotAllocated(x) • Predicate IsNotAllocated checks that memory x is not allocated at the moment where it has been used.

14. Examples • In the existing programming languages (like C), there are some functions that might lead to vulnerability if they are applied on very large arguments. • The use of a marked variable as an argument of the malloc function is a well-known example of such a vulnerability which expressed by the vulnerability detection condition Vdc3 below. • A variable is marked if for instance its value is obtained from a non secure source. This value may be produced by reading in a file, by asking a user for an input, etc. Vdc3 =malloc(S)/marked(S)

15. Examples • Good programming practice is to immediately check the return value of a memory allocation function even if this value is not used. The absence of such a checking statement is detected by the following vulnerability detection condition Vdc4: Vdc4=(u := malloc(S));notChecked(u, null)

16. From VCG to formal Vulnerability Detection Condition • Causes are classified in two categories: • Quantitative causes: denote the causes that can be detected and checked following a formal (even automatic) process without human intervention: « the use of a specific memory allocation » • Qualitative causes: a qualitative cause cannot be checked or evaluated without human intervention: « documentation is unclear » • We are only interested in quantitative causes.

17. From VCG to formal Vulnerability Detection Condition • Every quantitative cause in the graph is either an action or condition • An action denotes a particular point in a program where a task or an instruction that modifies the value of a given object is executed. For instance assigning a value to a variable, coppying in a buffer, etc • A condition denotes a particular state of a program defined by the value and the status of each variable. For a memory variable for instance, we can find out if it is allocated of free.

18. From VCG to formal Vulnerability Detection Condition • In a VCG, each path leading to the exit node denotes a potential dangerous scenario. • Every such scenario must contain one master action Act_Master which produces the related vulnerability. • All the other nodes of this path denote conditions {C1, …, Cn} under which the master action is executed. • Among these conditions, it may exist a particular condition Ck which must be satisfied by an action that should follow action Act_Master.

19. From VCG to formal Vulnerability Detection Condition • Let {P1,…, Pk,…, Pn} be the boolean predicates describing conditions {C1, …, Ck,…, Cn}. The formal vulnerability detection condition expressing this dangerous scenario is defined by: Act/(P1 … Pk-1… Pn); Pk • Finally, the vulnerability detection condition representing the vulnerability is defined as the disjunction of the all sub-vulnerability detection condition expressing each path : • Vcd1 … Vcdn

20. Example • - According to this example • There are four possibles scenarios • that may lead to the related vulnerability: • (1,2,4,5,7),(1,2,4,6,7),(1,3,4,5,7), • (1,3,4,6,7) • We will give the Vulnerability detection • condition associated to the scenario: • (1,2,4,5,7). • In this scenario the master action that • may lead to a vulnerability is • the use of an Allocation function (node 4). • This allocation may lead to a vulnerability if • it used under the following conditions: • Use of nonadapttive buffers, External data • Influences buffer size, Use of malloc/calloc/ • Realloc/alloca, return value of malloc is not checked.

21. Example • Use of nonadaptive buffers: • The program uses buffers whose size are fixed when they are allocated (allocation may take place at run-time using e.g. malloc, or at compile- time) • Non-adaptive buffers can only hold a specific amount of data; attempting to write beyond their capacity results in a buffer overflow. • For each declared nonadaptive buffer B, the following predicate holds: nonAdaptiveBuffer(B)

22. Example • External data influences buffer size: • The size of a dynamically allocated buffer is computed at least in part from user-supplied data. • This may allow the user to manipulate the buffer size. If a buffer is made too large, this may result in a denial of service condition; if it is too small, then it may result in a buffer overflow. • For each variable B whose value is produced from unsecure source, the following predicate holds: marked(B)

23. Example • Use of malloc/calloc/realloc/alloca: • the program uses C-style memory management functions, such as malloc, calloc, realloc or alloca to allocate memory. • For each memory function allocation f, the following predicate holds: memoryAllocation(f)

24. Example • return value of malloc function was not checked: • The program does not contain mechanisms to deal with low memory conditions in a safe manner (i.e. deal with NULL return values from malloc). • Running out of memory in programs that are not written to handle such a situation may result in unpredictable behavior that can possibly be exploited. • This cause is detected when the return value u of an allocation function is not immediately followed by a check statement. For each value u returned from an allocation memory function, the following formula is defined: NotChecked(u,null)

25. Example • The vulnerability detection condition expressing this scenario is then defined by: • This last vulnerability detection condition expresses a potential vulnerability when a given allocation function f is used with a non-adaptive buffer B whose value is produced from a non secure source.

26. Procedure for vulnerabilities detection • Step 1: Vulnerabilities description is provided and his VCG is obtained • Step 2: Interpretation of the VCG to obtain VDCs • Step 3: Extraction of execution traces from local observers • Step 4: Transformation of traces in an adapted format • Step 5: Vulnerability checking

27. New approach Current Goals • model attacks to generate attack scenarios to be injected during runtime; • detect the protocol vulnerabilities in the presence of malicious faults (attacks). • Future Goal • detect program vulnerabilities using attack trees

28. New approach Attack tree (graphical and textual notation) Attack scenarios: <G8,G4>, <G9,G4>, <G2>, <G10, G11>, <G13>, <G14>, <G15>

29. New approach Steps • Definition of attacker capabilities (injector). • Identification of attacker goals. • Construction of attack tree and selection of attack scenarios. • <attacker capability, testing architecture> • Values: P–Possible / I–Impossible. • Refinement of the selected scenarios. • Mapping attacks into faults. • <trigger, condition, action> • trigger: reception of a specific message. • condition: message fields content, state variables. • action: intercept, corrupt, drop, replicate, delay. • Transform attacks scripts

30. Conclusions • Vulnerabilities exist • Security is critical • Use of VCG to test for vulnerability detection • Vulnerability Detection Condition • Use of models • Passive testing using program traces • Detect vulnerabilities using attack trees approach