Securing Network Software using Static Analysis

Transcription

1 Securing Network Software using Static Analysis Lauri Kolmonen Helsinki University of Technology Abstract Writing network software is not easy and developing secure network software is even more challenging. A more efficient solution is required because using security professionals for software security reviews and audits is expensive and prone to human errors. In this paper, we survey a range of static analysis tools that stress software security on multiple different programming languages. We also present the underlaying methods these tools use for efficiently finding network application vulnerabilities. With the help of static analysis tools, software developers can efficiently identify and eliminate many types of common vulnerabilities well before the software is deployed. KEYWORDS: Static analysis, network software, security 1 Introduction Developing network software is not easy and developing secure network software is even more challenging. One of the weaknesses of such software is its open nature. For example, a web server is exposed to the whole of the Internet, which means in turn that almost anyone can exploit the software vulnerabilities. Statistics from the CERT Coordination Center [2] (Fig. 1) show that the number of reported software vulnerabilities have been rising rapidly since Figure 1: Software vulnerabilities reported to CERT Set against this background, it is clear that openness presents particular security requirements to developers of network software. To make matters worse, it is easy for inexperienced developer to introduce a vulnerability without realizing it. Fortunately, tools for identifying and eliminating these kinds of vulnerabilities exist. One helpful method is static analysis, which can find programming errors or insecure functions that may lead to a range of security problems. With many static analysis tools available, software developers have the possibility to filter out many of the common security problems in the source code with fairly low effort and cost compared to e.g. code reviews. 2 Static Analysis in Brief Static analysis means analyzing the code without executing it. This analysis can be preformed based on software source code, binary format (native executable or bytecode) or both. With the help of static analysis, the developers are able to perform quick, thorough and objective check of the source code to pinpoint different types of issues they are concerned about. For example, to ensure that source code adheres to a certain coding standard, programmers might be required to run a static analysis tool designed to check these conventions on a regular basis (e.g. before committing the code to repository), and then to change the code to follow these conventions. No static analysis tool is perfect. All of them produce some number of false alarms (called false positives) or leave some important issues unnoticed (false negatives), or both. The balance between false positives and false negatives is a compromise which depends on the nature of the tool. Skimming through a long list of issues that contains too many unwanted results can be a tedious task thus reducing the usability. For example, as a style checker only checks programming style, it can accept some false negatives in order to reduce the list of false positives without causing major problems. On the contrary, static analysis tools that stress software security usually try minimize the number of false negatives in order to avoid leaving out any possibly important problems. As a result, they tend to generate more false positives. There are other trade-offs as well. In order to process thousands or even millions lines of code efficiently within reasonable time limits, the tools have to make compromises in the depth of the analysis. Different tools aim for different execution time: some tools provide almost instant results and can be built as a part of the development environment (e.g. a simple syntax checker found in almost every modern

2 IDE), whereas the others might require many hours to complete and suit better to be used, for example to make manual code reviews more effective. 2.1 Static Analysis and Security With the help of static analysis tools, developers can improve reliability, security and overall quality of software by detecting typical programming errors early in development process. This gives the programmers an opportunity to correct these problems in advance, before the deployment of the software and before a malicious user has a possibility to exploit program vulnerability. Static analysis provides feedback of certain security issues in the source code. These tools should not be utilized to verify software security because they only detect set of predefined security issues. However, static analysis tools enable the software developers or test engineers to perform fast and frequent checks to detect vulnerabilities, which makes these tools suitable to be used alongside with manual code review and security audit processes to improve the efficiency, thus also lowering the costs of these sessions. It is relatively easy to create security problems with programming languages. Static analysis is at its best for finding these kinds of general problems from the program code. More complex defects that are only visible in the program design can be found through different methods, such as architectural analysis. 3 Static Analysis Methods There are many different kinds of methods for performing static analysis and most of the current tools exploit various different methods for examining the program code. This section describes some of these methods the tools use to detect problems. Historically, developers have performed static analysis by means of well-known UNIX tool, namely grep [5]. Armed with set of predefined regular expressions, grep can be used to find dubious lines of code that need manual inspection. However, employing regular expressions for finding blocks of code has many disadvantages. First, regular expression syntax is difficult to read and defining new rules is cumbersome. This approach also ignores an important property of software the actual structure of the program. For example, it is difficult to distinguish comment blocks from actual code using regular expressions or to do more detailed analysis. Grep can hardly be called a static analysis tool. It is more a general purpose tool for finding user defined pattens in a file, and has not been designed with software analysis in mind. The program lacks important knowledge of program syntax, structure and execution order. All real static analysis tools working on source code first have to transform it into a tokenized form. This means breaking source code file into a series of lexical tokens for easier processing[17]. This process is called lexical analysis. For example, by use of lexical analysis, the tools can create more detailed model of program, for example to separate unsafe function calls from innocent comments. While lexical analysis helps detecting some of the most straightforward security defects, most require more detailed analysis to be detected. In their book[6], West and Chess explain that to make this analysis possible, a tool has to build an abstract syntax tree (AST) from the tokenized form in order to understand program semantics. At this point, as the semantics of the analyzed program is known, a static analysis tool can perform more precise analysis by tracking control and data flow path of the program under analysis. This may be done on multiple different levels: on a function level, module or class level, or on a global level, considering interprocedural calls between all functions in the program[5]. The deeper the analysis context, more computation power it requires. 3.1 Model Checking Some of the tools presented in section 5 employ model checking for inspecting temporal safety properties, such as memory should be freed only once [6]. This can be done by transforming the property to be checked into a finite state automaton (the model) and then comparing the program to this model to detect a violation of a given safety property. 3.2 Taint Propagation Many of the typical attacks are result from trusting user input or failing to escape it correctly. Open Web Application Security Project (OWASP) lists top ten most serious web application vulnerabilities[14]. Insufficient input validation is the most common origin of software vulnerabilities and the top three positions in this ranking. Many of the static analysis tools use taint propagation to find software vulnerabilities which originate from failing to validate user input correctly. In taint propagation, the tool tracks the path of tainted input through program and examines the parts the input has effect on. For example, assigning a tainted variable to an another variable taints also the target. When tainted data reaches a sink, a program location that should not receive tainted data, static analysis tool reports a vulnerability alert. There are also functions that remove taint from a variable, typically performing different types of input validation. Another problem closely related to taint propagation is pointer aliasing. In order to ensure reliable taint propagation analysis, tool has to also perform alias analysis to understand relationships between variables that contain tainted data. 4 Network Application Vulnerabilities This section describes three most common security vulnerabilities concerning network software. All of these security problems are due to unvalidated user input, an issue discussed in Section 3.2.

3 4.1 Buffer Overflow Buffer overflows are one of the most common forms of security threats in software[18]. Programs implemented with C and C++ programming languages are very likely to have buffer overflow vulnerabilities because of their low-level access to memory and some common library functions that lack important bounds checking. This covers all network software written with C/C++, ranging from simple network tools to web servers and operating system protocol stacks. Buffer overflows occur when too much data is written to a fixed-length buffer without checking whether or not the data actually fits into memory allocated for the buffer. For example, C function strcpy copies string to an array. If the supplied string contains more data than is reserved for the array, function will overwrite memory locations following the array, causing a buffer overflow. Buffer overflow vulnerabilities enable malicious user e.g. to overwrite function return addresses and thereby allowing remote execution of arbitrary code. For example, Wilander[20] explains buffer overflows in more detail. 4.2 Cross-site Scripting Cross-site scripting (XSS) is a web application vulnerability that enables an attacker to execute remote code with the credentials of another user. For example, by entering (e.g. with URL parameter or via database) JavaScript code to a web site that displays unescaped user input, an attacker is able to execute arbitrary JavaScript commands with the access rights of the viewer and to steal the credentials of the user. OWASP ranks Cross-site scripting the topmost serious web application vulnerability of the year 2007[14]. More information about cross-site scripting can be found e.g. from CERT advisory 02/2000 [1]. 4.3 Injection Command injection means injecting arbitrary commands as input to an application, which subsequently executes commands without performing adequate input validation. SQL injection is a special form of command injection, directed against databases. SQL injection can occur when a unescaped malicious input is used to construct an a SQL database query. This enables execution of arbitrary SQL commands given by an attacker. As can be seen from PHP example below, the $name parameter is initialized from HTTP GET parameter and used to construct SQL query without any input validation. $name = $_GET[ name ]; $query = "SELECT address FROM users WHERE name = $name ;" $result = pg_query($query); This example functions as it should, returning and address corresponding to a name, if the name parameter really contains a name consisting of alphabets. But consider a situation where a malicious user sets the input to: ; DELETE FROM users WHERE = SQL query to be executed then becomes: SELECT address FROM users WHERE name = ; DELETE FROM users WHERE = ; Execution of this query would result deleting all the rows in users table, but any other kind of manipulation to backend database is also possible (e.g. changing user credentials for bypassing authentication). Catching SQL injection errors is closely related to web application and other database-driven network application development. 5 Static Analysis Security Tools Various static analysis tools for finding different kinds of security issues have been implemented and have been successfully used to detect security problems in many widely deployed programs. We will give some examples of these tools and programs later in this section. 5.1 Detection Rules A good static analysis tool separates the program logic and rules for detecting vulnerabilities. By using separate rules the tool makes possible for the users to extend or change the rules of the tool, thereby making the tool more diverse and flexible. However, this requires a special syntax for the rules, which is readable both by the human and the computer. Many of the tools use external files for defining the detection rules, but there are other methods as well, such as annotations. Some of the tools exploit annotations to document rules defining what kind of problems the tool should report and how the program is designed to behave. Annotations are written directly to program code. Special comment syntax or suitable annotation facility built into programming language is typically used for defining annotations. For example, Java programming language introduced annotations with the release of its version 5.0 to replace ad hoc annotation mechanisms. 5.2 Review of Current Tools Different programming languages pose different challenges for performing static analysis because of the different characteristics they have. For example, one of the main concerns of C/C++ programs are buffer overflow vulnerabilities, which are very easy to implement by accident (e.g. using gets function without bounds check. Scripting languages, such as PHP or Ruby, bring unique challenges for static analysis tools as they implement many dynamic properties. These properties include dynamic typing of variables (with implicit casts), lack of explicit variable declarations and dynamic inclusion of code[21]. Because of these unique programming language-specific features and problems, almost all of these static analysis tools are specialized to find issues only in one language. Below we list a number of tools for this purpose:

4 ITS4 by Cigital, Inc., one of the early static analysis security tools, concentrates on detecting function calls, such as gets() that may pose a security threat when used incorrectly. The tool performs basic lexical analysis, for example to separate comments from function calls, thus providing only little help detecting more complex and context specific security problems[16]. ITS4 supports C and C++ programming languages and it has separate vulnerability definition file. ITS4 is no longer officially supported by Cigital but the source code is available for any use that does not compete with Cigital s consulting practice. FlawFinder[19] is an open source tool distributed under the terms of the GNU Public License (GPL) designed for detecting risky function calls in C/C++ programs. Like ITS4, the tool employs lexical analysis to detect hazardous functions but uses built-in vulnerability database instead. Because of these properties, the tool is only to be used for detecting very basic vulnerabilities. RATS[10] (Rough Auditing Tool for Security) is also licensed under GPL, and is used for detecting security problems in various programming languages (C, C++, Perl, PHP and Python.) As ITS4 and FlawFinder, the tool exploits lexical analysis for performing the analysis and therefore only provides only rough analysis of certain relatively simple security problems, in other words, hazardous function calls. BOON[18], focuses solely on detecting buffer overflow vulnerabilities using integer range analysis. BOON ignores many important issues, such as pointer aliasing, statement order and interprocedural dependencies[6]. BOON has successfully been used to find buffer overflow vulnerabilities in popular software, for example in Linux net tools package [18]. Pixy is an open source tool for detecting taint-style vulnerabilities (cross-site scripting, SQL and command injection) in PHP code. Pixy uses flow-sensitive, interprocedural, and context sensitive data flow analysis to detect taint-style vulnerabilities[11]. Also literal and alias analysis is employed to gain better results [12]. Splint is an open source static analysis tool for finding software vulnerabilities in ANSI C code. The program uses annotations to find abstraction violations, unannounced modifications to global variables and other problems. The tool can also detect different types of buffer overflow and memory leak vulnerabilities [7]. LAPSE (Lightweight Analysis for Program Security in Eclipse) is an open source tool for detecting common web application security problems implemented with Java J2EE. The tools is available as a plugin for Eclipse IDE. LAPSE detects different types of tainted input vulnerabilities, including SQL injection, Cross-site scripting, cookie poisoning and parameter manipulation [13]. The ARCHER tool employs simulation-based approach for detecting memory access errors in C programs. It has a low false positive rate, does not need annotations, and scales well to handle programs with millions lines of code. One of the drawbacks of ARCHER is the lack of understanding C string operations, causing it to miss many common errors. The tool has found hundreds of errors in Linux kernel and other systems[22]. CQual is an open source tool that performs type-based analysis for example to detect deadlocks and format string vulnerabilities in C/C++ programs. The tools requires the user to define some annotations (type qualifiers) as a basis of taint propagation analysis it performs. The tools has been successfully used to finding potential deadlocks in Linux kernel[8]. WebSSARI (Web application Security via Static Analysis and Runtime Inspection) is a tool for detecting security vulnerabilities in PHP code. WebSSARI is also able to automatically insert runtime guards in sections that it finds possibly unsafe[9]. WebSSARI has been successfully used to find various security problems in multiple widely-used PHP software components. The Eau Claire is theorem prover based static analysis tool for identifying buffer overflows, file access race conditions and format string vulnerabilities in C programs. By default the tool can identify array bounds errors and null pointer dereferences. It also allows user to define specifications for checking custom security properties for functions[4]. MOPS (MOdel checking Program for Security) is a tool that employs model checking for detecting temporal safety property violations in C programs. Because of the formal approach of MOPS, it can reliably verify the absence of certain classes of vulnerabilities in a program.[3]. MOPS has been successfully used to detect multiple security vulnerabilities e.g. in Red Hat Linux[15]. SATURN is a framework for detecting violations of temporal safety properties in C programs. The tool is based on boolean satisfiability and has been used to detect multiple locking problems in Linux kernel. However, it can be used to detect many other types of problems as well, such as memory-leaks. 6 Static Analysis and Securing Network Applications In this section, we discuss the use of static analysis to improve security of network software. Many of the tools described in Section 5, can be used to enhance security of all kinds of applications. As a matter of fact, some of these tools have successfully found various vulnerabilities in known and widely deployed network applications and frameworks[13]. The term network software is very abstract and can mean just about any application connected to a network of some kind. Also the safety requirements of different network software varies a lot.

5 As stated in section 4, examples of typical attacks that exploit current network software are buffer overflow attacks, SQL injections or cross-site scripting (XSS). Previous section described many tools that can be used to detect these vulnerabilities in applications. We were pleased to find that there are multiple tools for detecting these very common vulnerabilities which are unfortunately easy to introduce. Especially tools such as Pixy, WebSSARI and LAPSE seem promising for eliminating web application vulnerabilities in common implementation languages, such as PHP and Java. Also there are many tools for detecting security problems in more low-level network applications such as web servers often implemented with C/C++. 7 Conclusions There are many static analysis tools available for improving network application security. However, because these tools are very language-specific, the implementation language may rule out useful tools. Static analysis tools can help to detect many complex security problems which otherwise would be left unnoticed. However, these tools are not perfect and the results always need human inspection. Static analysis tools are unable detect security problems that result from insecure software design but can help developers avoid many of the common mistakes which seem to occur in software over and over again. References [1] CERT. Malicious html tags embedded in client web requests. CERT Web Site, February [2] CERT. Cert statistics: Vulnerability remediation. CERT Web Site, September [3] H. Chen and D. A. Wagner. Mops: an infrastructure for examining security properties of software. Technical report, Berkeley, CA, USA, [4] B. Chess. Improving computer security using extended static checking. In SP 02: Proceedings of the 2002 IEEE Symposium on Security and Privacy, page 160, Washington, DC, USA, IEEE Computer Society. [5] B. Chess and G. McGraw. Static analysis for security. IEEE Security and Privacy, 2(6):76 79, [6] B. Chess and J. West. Secure Programming with Static Analysis. Addison Wesley, [7] D. Evans and D. Larochelle. Improving security using extensible lightweight static analysis. Software, IEEE, 19(1):42 51, [8] J. S. Foster, T. Terauchi, and A. Aiken. Flow-sensitive type qualifiers. Technical report, Berkeley, CA, USA, [9] Y.-W. Huang, F. Yu, C. Hang, C.-H. Tsai, D.-T. Lee, and S.-Y. Kuo. Securing web application code by static analysis and runtime protection. In WWW 04: Proceedings of the 13th international conference on World Wide Web, pages 40 52, New York, NY, USA, ACM Press. [10] S. S. Inc. Rats rought auditing tool for security, [11] N. Jovanovic, C. Kruegel, and E. Kirda. Pixy: A static analysis tool for detecting web application vulnerabilities (short paper). In SP 06: Proceedings of the 2006 IEEE Symposium on Security and Privacy (S&P 06), pages , Washington, DC, USA, IEEE Computer Society. [12] N. Jovanovic, C. Kruegel, and E. Kirda. Precise alias analysis for static detection of web application vulnerabilities. In PLAS 06: Proceedings of the 2006 workshop on Programming languages and analysis for security, pages 27 36, New York, NY, USA, ACM Press. [13] V. B. Livshits and M. S. Lam. Finding security vulnerabilities in Java programs with static analysis. In Proceedings of the 14th Usenix Security Symposium, pages , Aug [14] OWASP. The ten most serious web application vulnerabilities. OWASP Web Site, October [15] B. Schwarz, H. Chen, D. Wagner, J. Lin, W. Tu, G. Morrison, and J. West. Model checking an entire linux distribution for security violations. In ACSAC 05: Proceedings of the 21st Annual Computer Security Applications Conference, pages 13 22, Washington, DC, USA, IEEE Computer Society. [16] J. Viega, J. Bloch, Y. Kohno, and G. McGraw. Its4: A static vulnerability scanner for c and c++ code. acsac, 00:257, [17] J. Viega, J. T. Bloch, T. Kohno, and G. McGraw. Tokenbased scanning of source code for security problems. ACM Trans. Inf. Syst. Secur., 5(3): , [18] D. Wagner, J. S. Foster, E. A. Brewer, and A. Aiken. A first step towards automated detection of buffer overrun vulnerabilities. In Network and Distributed System Security Symposium, pages 3 17, San Diego, CA, February [19] D. A. Wheeler. Flawfinder, [20] J. Wilander and M. Kamkar. A comparison of publicly available tools for dynamic buffer overflow prevention. In Proceedings of the 10th Network and Distributed System Security Symposium, pages , San Diego, California, February 2003.

6 [21] Y. Xie and A. Aiken. Static detection of security vulnerabilities in scripting languages. In USENIX-SS 06: Proceedings of the 15th conference on USENIX Security Symposium, pages 13 13, Berkeley, CA, USA, USENIX Association. [22] Y. Xie, A. Chou, and D. Engler. Archer an automated tool for detecting buffer access errors. In Proceedings of ESEC/FSE 2003, 2003.