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 OcaShanai Ardi, David Byers, Nahid Shahmehri

Presented by Willy Jimenez, Telecom Sudparis

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)

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

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

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.

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

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

Vulnerability Cause Graphs (2)

CVE-2006-3192

Unchecked integer multiplication

External data influences buffer size

Use of nonadaptive buffers

The return value of malloc is not checked

Use of malloc/calloc/realloc/alloca

(1)

(2)

(3)

(4)

(5)

(6)

Failed to check input parameter to malloc

(7)

This VCG models a CVE-2005-3192Vulnerability (a remote buffer overflow in xpdf viewer)

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

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.

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

Formal representation of vulnerabilities

If Vdc1 and Vdc2 are vulnerability detection conditions, then (Vdc1 Vdc2) and (Vdc1 Vdc2) are vulnerability detection conditions too.

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.

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)

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)

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.

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.

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.

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

Example

CVE-2006-3192

Unchecked integer multiplication

External data influences buffer size

Use of nonadaptive buffers

The return value of malloc is not checked

Use of malloc/calloc/realloc/alloca

(1)

(2)

(3)

(4)

(5)

(6)

Failed to check input parameter to malloc

(7)

- According to this exampleThere are four possibles scenariosthat 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 detectioncondition 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 dataInfluences buffer size, Use of malloc/calloc/Realloc/alloca, return value of malloc is not checked.

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

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)

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

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)

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.

)),((;

)(

)(

)(

/)(: nulluNotChecked

Bmarked

BeBuffernonAdaptiv

fcationmemoryAllo

Bfu

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

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

New approach

Attack tree (graphical and textual notation)

Attack scenarios: <G8,G4>, <G9,G4>, <G2>, <G10, G11>, <G13>, <G14>, <G15>

New approach

Steps

1. Definition of attacker capabilities (injector).

2. Identification of attacker goals.

3. Construction of attack tree and selection of attack scenarios.

1. <attacker capability, testing architecture>

2. Values: P–Possible / I–Impossible.

4. Refinement of the selected scenarios.

5. Mapping attacks into faults.1. <trigger, condition, action>

2. trigger: reception of a specific message.

3. condition: message fields content, state variables.

4. action: intercept, corrupt, drop, replicate, delay.

6. Transform attacks scripts

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

Conclusions