Detecting known vulnerablities from within design and development tools SHIELDS The research leading to these results has received funding from the European.

Similar presentations

Presentation on theme: "Detecting known vulnerablities from within design and development tools SHIELDS The research leading to these results has received funding from the European."— Presentation transcript:

1
Detecting known vulnerablities from within design and development tools SHIELDS 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. 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

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

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

13
Examples  Vulnerability detection condition Vdc 1 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: Vdc 1 = 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 Vdc 3 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. Vdc 3 =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 Vdc 4 : Vdc 4 =(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 {C 1, …, C n } under which the master action is executed.  Among these conditions, it may exist a particular condition C k which must be satisfied by an action that should follow action Act_Master.

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
 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) Example

22
 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
 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) Example

24
 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.

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