SEC-MDA'09 Workshop

1. SEC-MDA'09 Workshop Software Vulnerabilities, Prevention and Detection Methods: A Review Willy Jimenez, Amel Mammar and Ana Cavalli CNRS Samovar Lab/UMR I157 TELECOM & Management SudParis {name.lastname}@it-sudparis.eu

2. Outline • INTRODUCTION • SOFTWARE VULNERABILITIES • Examples of Vulnerabilities • Vulnerability Model • PREVENTING SOFTWARE VULNERABILITIES • Software Inspection • Security Activity Graph • DETECTING SOFTWARE VULNERABILITIES • Static and Dynamic Techniques • OUR APPROACH • CONCLUSIONS

3. Introduction • Our contribution to European Project Shields • http://www.shieldsproject.eu/ • Our main goals: • 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)

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. Examples of Vulnerabilities • 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. Vulnerability Modelling • From Wikipedia, “A model is a pattern, plan, representation (especially in miniature), or description designed to show the main object or workings of an object, system, or concept”

7. Vulnerability Modelling VULNERABILITY CAUSE GRAPH: “is a directed acyclic graph that contains one exit node representing the vulnerability being modeled, and any number of cause nodes, each of which represents a condition or event during software development that might contribute to the presence of the modeled vulnerability”.

8. Preventing Vulnerabilities SOFTWARE INSPECTIONS: consists in reading or visually inspecting the program code or documents in order to find any defects and correct them early in the development process. • Vulnerability Inspection Diagram: is a flowchart-like graph that guides developers to check the software to detect the presence of vulnerabilities based on the knowledge of experts • Security Goal Indicator Trees: is then a graph where the root is a security goal and its subtree are indicators or properties that can be checked for achieving that goal

9. Preventing Vulnerabilities SECURITY GOAL INDICATOR TREE

10. Preventing Vulnerabilities SECURITY ACTIVITY GRAPHS: are a graphical representation that is associated with causes in a VCG. SAGs indicate how a particular cause can be prevented following a combination of security activities during the development process

11. Detecting Vulnerabilities • STATIC TECHNIQUES: program is not executed • Pattern Matching • Lexical Analysis • Parsing • Type Qualifier • Data Flow Analysis • Taint Analysis • Model Checking

12. Detecting Vulnerabilities • DYNAMIC TECHNIQUES: program is executed • Fault Injection • Fuzzing Testing • Dynamic Taint • Sanitization

13. Our approach • Vulnerability Detection Condition • Objective: to automate the vulnerability detection process using passive testing • The Vulnerability Detection Condition formalism: VDC ::= a/P(Var, Act) | a[/P(Var, Act)]; P’(Var, Act) Where: • Act: action names • Var: variables • P: predicates on (VarAct). • a: denotes a master action that produces the vulnerability

14. Our approach • Use of Vulnerability Detection Condition (VDC) with Vulnerability Cause Graph • In the VCG there are 4 possible scenarios or paths that may lead to the vulnerability, thus a VDC has to be defined for each one: • (1,2,4,5,7),(1,2,4,6,7) • (1,3,4,5,7),(1,3,4,6,7) • Consider scenario (1,2,4,5,7): the master action is in node 4 (use of malloc). • This action may lead to a vulnerability if it occurs under the following conditions: • Use of non adaptive buffer (1) • External data influences buffer size (2) • Return value of malloc function is not checked (5)

15. æ ö memoryAllocation( f ) Ù ç ÷ = Ù u : f ( B ) / nonAdaptiveBuffer(B) ; notChecked(u, null) ç ÷ ç Tainted( B) è ø Our approach • The VDC for scenario (1,2,4,5,7): • It is then instantiated to a specific programming language in order to detect this vulnerability in the evaluated code ÷

16. Our approach Attack Tree and Fault Injection for Security Testing

17. Our 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

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

19. Our 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

20. Conclusions • Vulnerabilities exist • Models help comprehension and reuse • Inspection is a first approach to detect/prevent vulnerabilities • Vulnerability detection using dynamic/static analysis or a combination of both • Static requires source code and covers all possible execution paths • Dynamic detects problems on running code but coverage is limited and depend on test cases

21. Conclusions Vulnerability detection using vulnerability models Vulnerability detection using attack trees

22. Questions?