A Method of Detecting Vulnerability Defects Based on Static Analysis

A Method of Detecting Vulnerability Defects Based on Static AnalysisXiao Qing1,2 , Yang Zhao Hong1,2 , Gong Yun Zhan11State Key Laboratory of Networking and Switching Technology, Beijing University of Posts and Telecommunications,Beijing 100876,China2Department of Information Engineering of the Academy of Armored Force Engineering, Beijing 100072, Chinaxqing0923@ABSTRACT: This paper proposes a method for detecting vulnerability defects caused by tainted data based on state machine. It first uses state machine to define various defect patterns. If the states of state machine is considered as the value propagated in dataflow analysis and the union operation of the state sets as the aggregation operation of dataflow analysis, the defect detection can be treated as a forward dataflow analysis problem. To reduce the false positives caused by intraprocedural analysis, the dynamic information of program was represented approximately by abstract value of variables, and then infeasible path can be identified when some variable’s abstract value is empty in the state condition. A function summary method is proposed to get the information needed for performing interprocedural defect detection. The method proposed has been implemented in a defect testing tools.KEYWORDS: vulnerability defects; static analysis; function summary; interval computation; state machineI.INTRODUCTIONBugs in software are costly and difficult to find and fix. In recent years, many tools have been developed for automatically finding bugs by analyzing source code or intermediate code statically, using techniques such as defects pattern matching, data flow analysis, type systems, model checking, and theorem proving. For example, SDV reported 206 defects over 126 WDM drivers, of which they have carefully investigated 65 and found 53 true errors [1]. MC found 100 security errors in Linux and OpenBSD, over 50 of which have led to kernel patches [2].This paper proposes a method to detect vulnerability defects caused by tainted data. It first proposes an intraprocedural defect detection method based on traditional dataflow analysis. According to the defects features, it then proposes an interprocedural defect detection method based on function summary. There are three major phases to detect vulnerability defects: (1) Define defects patterns. Defects patterns define the patterns in code that often indicate defects. The tool can never report a defect outside its defect patterns set. (2) Run the software testing tools based on defect patterns. The defect patterns analysis engines identify defects in the codes using static analysis techniques, such as control flow tracing and dataflow tracing. (3) Check the output from the tool. Static analysis is a computationally undecidable problem. So the output from the tool should be checked to identify true defects. The most common complaint leveled against static analysis tools that target bugs is that they produce too many false positives.II.A SQL INJECTION EXAMPLE SQL injection is a vulnerability caused by unchecked orimproperly checked database input.Example 1:String accountNumber= req.getParameter("accountNumber");String query = "SELECT * FROM user_data WHERE userid ='" + accountNumber + "'";Statement statement =con.createStatement(……ResultSet results = statement.executeQuery(query);As to the example 1, the parameter accountNumber is an unchecked input for the query. As to Oracle Database, if the query was issued with the malicious option: ’OR 1=1;-- , it would generate a script that allows user to pass the password testing with the following command[3]:SELECT * FROM user_data WHERE userid =’’ OR 1=1;--To deal with SQL injection vulnerability, the input should be validated properly to filter strings that can affect the SQL syntax such as ‘,’’, :,=, select, exec, insert, etc.III.VULNERABILITY DEFECT CAUSED BYTAINTED DATAMany property checking tools focus on temporal safety properties. A temporal safety property specifies an ordered sequence of events that a program must not carry out. When a property checking tool discovers that the code might not match the specification, it traditionally explains its finding to the user by reporting a counterexample: a hypothetical event or sequence of events that takes place within the program that will lead to the property being violated [4]. The property checked can be defined by a state machine.Definition 1: Defect patterns state machine(DPSM):the Finite State Machine to define defect patterns includes, state set D, state transition set T and transition condition set Conditions.otherDerrorstartD∪},${$=,DConditionsDT→×:.start$and error$ representthe start state and the error state,otherD represents the other state set.For example, improperly checked input defect pattern can be defined by DPSM as in Fig 1.2010 International Forum on Information Technology and ApplicationsFigure 1. Improperly checked input defect pattern An instance of DPSM is created for every input site in the program, and all new created DPSM instances begin with start state. If the program gets an outside input, DPSM reaches the tainted state. In the tainted state, if this input is used directly in a vulnerable operation, DPSM reaches the error state and a vulnerability defect is reported.IV.METHOD TO DETECTING VULNERABILITY DEFECT CAUSED BY TAINTED DATA Since vulnerability defect caused by tainted data is defined by a DPSM, the testing method includes two parts: the state transition rules and an algorithm to transverse the control flow graph and compute the state transition using these rules.A.State Transition Rules Based on Taint PropagationSecurity tools need to know which values in a program an attacker could potentially control. Using dataflow to determine what an attacker can control is called taint propagation[4]. By taint propagation, we can know where information enters the program and how it moves through the program. For example, a program that contains an exploitable SQL injection vulnerability almost always contains a dataflow path from an input function to a database operation.State transition rules based on Taint Propagation include: Entry-point rules, Source rules, Sink rules, Pass-through rules and Cleanse rules[4]. Entry-Point rules enable DPSM reach the start state. Source rules enable DPSM reach the tainted state. Pass-through rules will increase the tainted data set. Cleanse rule enable DPSM reach the untainted state. Sink rules define program locations that should not receive tainted data, which can transit DPSM’s state from tainted to error.B.Intraprocedural Defect Testing methodIf the possible state sets of every DPSM are considered as the value propagated in dataflow analysis and the union operation of the state set as the aggregation operation of dataflow analysis, the defect detection can be treated as a forward dataflow analysis problem.Traditional dataflow problem can be solved using iteration method and get the Maximal Fixed Point (MFP) solution[5], which is path insensitive. Before introducing proposed path sensitive defect testing method, we first give some definitions.Definition 2: Abstract Context C: Abstract context is used to represent approximately the variable value,mainAbstractDoVariablesC×:,Variables re present the variable set,mainAbstractDo represent variable abstract domain.)(iC represents variable i’s value in C:⎩⎨⎧∈=elseCv iifviCΤ),()(In this paper, we use interval abstract domain to represent variable’s abstract value [6].Definition 3: Path conditions: If program reaches the control flow graph’s node by path S, then the restriction to the variable value by condition predicates and assumptionoperations can be denoted as,sC, which is called path conditions of S in node .Definition 4: State conditions: If program reaches the control flow graph’s node by path S and DPSM’s state is changed to σalong S, ,s C can be considered as the state condition ofσ. The state with state conditions can be denoted as}:{,sCσ.State conditions can be used to catch the path context and get rid of the infeasible paths. It implies that the state is computed erroneously on an infeasible path when some variable’s abstract value is empty in its state condition. Therefore all these contradictory states will be eliminated at every node in the control flow graph.To avoid the path exponential explosion of full path analysis, state conditions of the same state are merged in merge nodes of control flow graph. The path sensitive defect testing algorithm is as follows:][nin: Possible state set of every DPSM before node n;][nout: Possible state set of every DPSM after node n;][nkill: Removed possible state set of every DPSM on node n;][ngen: New generated possible state set of every DPSM on node n;entry: The entry node of the control flow graph;)(npred: Predecessor nodes of node n;Merge: Set of control flow merge node;Input: Control flow graph and instances of DPSM;Out: Potential defects.any;:][Φ=∈n in do N n each for ;:true change = begin change while do ;:false change =begin do N n each for ∈ then entry n if = };{][start n in =else ;][:][)(∪n pred p p out n in ∈=then merge n if ∈Merge n in C n in i n s i i //;][,:][,⎪⎭⎪⎬⎫⎪⎩⎪⎨⎧∈==σσσσσ∪];[:n out oldout =]);[][(][][n kill n in n gen n out −∪= defect a report then n out error if ][$∈true change then oldout n out if =≠:][ end endIn the location of comments Merge , State conditions of the same state are merged in merge nodes of control flow graph to avoid path exponential explosion with the cost of losing some precision. When computing ][n kill , the state conditions are updated. The state will be deleted if there are a variable in its state conditions, whose abstract value is Φ. C. Interprocedural defect testing methodIn order to realize context interprocedural analysis, the context information of a function call was represented using defect related function summary. Taking function as the basic unit, function summary can be considered as function’s abstract semantics as to defect testing.Definition 5: Function summary: function summary includes three sets that catch the information that may change DPSM’s state,},,{Pr Features ions Postcondit s econdition Summary = s econdition Pr represents the information set need checking before calling the function. ions Postcondit represents the information set that may change program’s context after calling the function. Features represents the feature information set that may change DPSM’s state when calling the function.As to vulnerability defects caused by tainted data, we need only consider Features , which includes four parts:Tainted source feature: tainted source feature can be denoted as <m,n>, which means calling function m may cause parameter n to be tainted (function return is considered as parameter 0).Taint propagation feature: taint propagation feature can be denoted as <m,ns,nd>, which means calling function m may cause parameter nd to be tainted if parameter ns is tainted.Cleanse feature: cleanse feature can be denoted as <m,n>, which means calling function m may cause n parameter to be untainted.Sink point feature: sink point feature can be denoted as <m,n>, which means calling function m may cause trigger sink rule if n parameter is tainted.Function summary is computed in a hierarchical bottom-up manner according to the function call graph. Library functions' function summaries are treated as configurations of the tool. Considering recursive functions, function summary computing is implemented by iteration. The interprocedural defect testing algorithm is as follows:Input: Function call graph and function summaries of library functions;Out: Potential defects;do graph call in f each for ;worklist to f addbegin do empty not is worklist while ;worklist from f node a remove ;:f of Summary get old = ;int analysis al raprocedur do;:f for Summary new generate new = begin then new old if ≠do f calls that graph call in g each for then worklist in not is g if ;worklist to g add end endV.I NTRODUCTION OF DTSThe proposed algorithm has been implemented in a defect testing system (DTS), which is a tool to catch defects in source code using static testing techniques. Its core features include defect patterns driven, high efficiency and less false positive. Fig 2 shows DTS’s Architecture.Figure 2. DTS’s ArchitectureVI. E XISTING TOOLS AND TECHNIQUESThere are many kinds of static analysis tools, each with different goals, such as type checking, style checking, program understanding, program verification, property checking, bug finding, and security review. The bug find tools are most similar to DTS. Cqual [7] is a static analysis tool based on type system. Prefix [8] is a static defect detecting tool which is very similar as DTS. Findbugs [9] does an excellent job of identifying bugs in java code. Coverity [10] makes a bug finder for C and C++. Microsoft’s Visual studio 2005 includes the \analyze option that checks for common coding errors in C and C++. Klocwork [11] offers a combination program understanding and bug finding static analysis tool that enables graphical exploration of large programs. Fortify [12] is a security-focused static analysis tool.VII. C ONCLUSIONThis Paper proposes a method for detecting vulnerability defects caused by tainted data based on state machine. To reduce the false positives caused by intraprocedural analysis, a function summary method is proposed to get the information needed for performing interprocedural defect detection. The method proposed has been implemented in the defect testing tools-DTS.A CKNOWLEDGMENTThis paper is supported by the National 863 projects of China under Grant No.2007AA010302 and 2009AA012404.R EFERENCES[1] T. Ball, E. Bounimova, B. Cook, V. Levin, J. Lichtenberg, C.McGarvey, B. Ondrusek, S. K. Rajamani, and A. Ustuner. Thorough Static Analysis of Device Drivers ，EuroSys 2006.[2] Junfeng Yang ，Can Sar ，and Dawson Engler. eXplode: aLightweight ，General System for Finding Serious Storage System Errors. Proceedings of the USENIX Symposium on Operating Systems Design and Implementation (OSDI) Seattle ，Washington ，November ，2006.[3] V. B. Livshits and M. S. Lain, Finding Security Vulnerabilities inJava Applications with Static Analysis[C], In Proceedings of the 14th Usenix Security Symposium, 2005;271-286.[4] B. Chess and J. West, Secure Programming with Static Analysis [M].Boston, Addison-Wesley, 2007.[5] Aho,A. Lam,M. Sethi, R. and Ullman, J. CompilersPrinciples,Techniques,and Tools[M]. New York: Addison-Wesley, 2006,626-632.[6] Yang ZH,Gong YZ,Xiao Q,Wang YW.The Application of IntervalComputation in Software Testing Based on Defect Pattern[J],Journal of Computer-aided Design & Computer Graphic ,2008,20(12):1630-1635.[7] Foster, J. Terauchi, T. and Aiken, A. Flow-Sensitive TypeQualifiers[C], Proceedings of the 2002 ACM SIGPLAN Conference on Programming Language Design and Implementation, Berlin, 2002,1-12.[8] Bush,W., Pincus,J. and Sielaff,D. A static analyzer for findingdynamic programming errors[J]. Software Practice and Experience, 2000,30(7): 775-802.[9] / [10] [11] [12] 。