Hugbúnaðarverkefni 2 - Static Analysis

Transcription

1 vulnerability/veila buffer overflow/yfirflæði biðminnis Server down? Again! Hugbúnaðarverkefni 2 - Static Analysis Fyrirlestrar 15 & 16 Buffer overflow vulnerabilities safe? safe? C code 11/02/2008 Dr Andy Brooks 1

2 Case Study Dæmisaga Reference Testing Static Analysis Tools using Exploitable Buffer Overflows from Open Source Code, Mish Zitser et al, SIGSOFT 04/FSE-12 pp , ACM 11/02/2008 Dr Andy Brooks 2

3 worm/snákur denial of service/miðlunarsynjun 1. Introduction Worms on the internet exploit buffer overflow vulnerabilities in server software. Arbitrary code can be run on the victim s server. Server software can be made to crash resulting in a denial of service (DoS). About 1/3 of all severe remotely exploitable vulnerabilities are buffer overflow vulnerabilities. 11/02/2008 Dr Andy Brooks 3

4 patch/bót, bútur af kóta 1. Introduction Figure 1. Cumulative buffer overflow vulnerabilities found in BIND, WU-TFPD, and Sendmail server software. 24 As soon as a patch is released, another source of vulnerability is revealed... 11/02/2008 Dr Andy Brooks 4

5 legacy software/fornbúnaður space complexity/rýmisflækjustig time complexity/tímaflækjustig 1. Introduction Static analysis is the only approach that eliminates both buffer overflows and their effects and that can be applied to the vast amounts of open-source legacy C code in widely-used open-source software. C was designed with space and performance in mind, not safety. Direct pointer manipulations can be made without any bounds checking. Many security-critical programs have been written in C. 11/02/2008 Dr Andy Brooks 5

6 performance/frammistaða overhead/umstang stack/stafli 1. Introduction Dynamic approaches that detect buffer overflows at run-time... turn into DoS attacks because a program halts in order to prevent a buffer overflow. StackGuard places a special value ( canary ) on the stack next to the return address and checks this value has not been changed before jumping. Performance overheads have been measured up to 40%. 11/02/2008 Dr Andy Brooks 6

7 1. Introduction The goals of the study The efficiency (false positives) and effectiveness (true positives) of static analysis detection of buffer overflows is not well known. The authors used a known collection of 14 remotelyexploitable buffer overflows from open-source server software. The first goal was to determine how well several static analysis tools detected these overflow vulnerabilities. A second goal was to characterize the buffer overflows. A third goal was provide a collection of examples of buffer overflows to help in the development of static analysis tools. 11/02/2008 Dr Andy Brooks 7

8 lexical analysis/lesgreining RATS and ITS4 RATS and ITS4 are simple lexical analysis tools which suffer from high false positive rates. They were excluded from the study. 11/02/2008 Dr Andy Brooks 8

9 syntax/málskipan call graph/kallrit function/aðgerð pointer/bendir loop/lykkja ARCHER (ARRay CHeckER) 2. Static Analysis Tools Inter-procedural Abstract syntax trees Approximate call graph Function pointers (C, C++) are not modelled Heuristics used to reduce false positives Heuristics used to analyse loops ARCHER has been used previously to analyse 2.6 million lines of open-source code and reported 215 warnings of which 160 were true security violations. 11/02/2008 Dr Andy Brooks 9

10 f f2 f3 f4 f5 11/02/2008 Dr Andy Brooks 10

11 2. Static Analysis Tools BOON (Buffer Overrun detection) Models string buffer manipulation only. Strings are modelled by a pair of integers: number of bytes allocated number of bytes used An integer range constraint is created for every use of a string function across a program. Control flow and statement order is ignored. The analysis is limited. BOON has been used previously to analyse Sendmail and reported 44 warnings of which only 4 were actual buffer overflows. 11/02/2008 Dr Andy Brooks 11

12 2. Static Analysis Tools Polyspace C Verifier Commercial tool based on abstract interpretation Polyspace C Verifier has been used previously to analyse Mars Exploration Rover (MER) software. Software had to be broken manually into 20-40K lines of code blocks. The tool did not scale to industrially-sized systems. MER software mainly suffered from access to uninitialized variables. A 30K block involved typically 5000 operation checks. One interesting defect was a function which returned the address of a local variable. False alarm rate (unverified) was between 10% and 20% of operation checks. 11/02/2008 Dr Andy Brooks 12

13 2. Static Analysis Tools SPLINT (Secure Programming Lint) SPLINT extends LCLINT to detect buffer overflows and other security violations. Several light weight static analysis techniques. Inter-procedural analysis possible with the aid of source annotations. Heuristics are used to model control flow and common loop constructs. SPLINT has been used previously to analyse WU-FTP source code (without annotations) and reported 166 warnings of which 25 were real. 11/02/2008 Dr Andy Brooks 13

14 LCLint -> SPLINT Early versions of LCLint assumed loops went round zero or one times. Not a useful simplification for buffer overflow analyses. To know if buf[i] is a possible buffer overlow, the range of values i can take must be known. SPLINT exploits the fact programmers write loops using certain code idioms or patterns (like FindBugs). 11/02/2008 Dr Andy Brooks 14

15 SPLINT loop heuristic for (index = 0; expr; index++) body Typically expr and body do not modify index, and if body does not contain a break, the number of iterations can be determined from expr. But variables in the body could alter index... 11/02/2008 Dr Andy Brooks 15

16 UNO Uninitialized variables, dereferencing Nullpointers, Out-of-bound array indexing. UNO makes use of a public domain compiler extension ctree to generate a parse tree for each procedure. The analysis is not inter-procedural. Control flow graphs analyzed by a model checker. UNO previously found no array indexing errors in two open-source software applications but reported 58 warnings about variables declared but not initialized or used, of which only 5 were false positives. 11/02/2008 Dr Andy Brooks 16

17 retrospective analysis/afturvirk greining 3. Open Source Test Cases BIND, most popular DNS server WU-FTPD, a popular FTP dæmon Sendmail, a mail transfer agent 14 severe buffer overflow vulnerabilities were selected for a retrospective analysis. Could the static analysis tools have detected these vulnerabilities? 11/02/2008 Dr Andy Brooks 17

18 Problems with scale Splint could not analyze all of Sendmail 146K LOC ARCHER terminated with a division-by-zero exception during analysis of Sendmail. PolySpace ran for four days on Sendmail before a fatal internal error occurred. The solution to these problems was to create smaller model programs ( lines) which incorporated the vulnerabilities. 11/02/2008 Dr Andy Brooks 18

19 Smaller model programs ( lines) Every attempt was made to preserve the general structure and complexity of the vulnerable code when creating these models. If a buffer was declared in one function and overflowed in another, or if it was accessed via some complicated loops and conditionals, then the model did so as well. It took between 5-7 hours to construct each smaller model program. Inputs were arranged which demonstrated buffer overflow on the smaller model programs. 11/02/2008 Dr Andy Brooks 19

20 BAD and OK versions Two versions of the smaller model programs were created. The BAD version contained one or more buffer vulnerabilities. The OK version was fixed according to the patch file distributed by the code maintainers. Though it cannot be certain the OK versions were free of vulnerabilities. 11/02/2008 Dr Andy Brooks 20

21 Table 2 of 14 Vulnerabilities Simple name Reason BIND-1 Size argument of memcpy (copy memory block) not checked BIND-2 Negative arg to memcpy underflows to large positive int BIND-3 Size argument of memcpy not checked BIND-4 Use of sprintf() without proper bounds checking SM-1, crackaddr Upper bound increment for a > char but not decrement for < SM-2 gecos field copied into fixed-size buffer without size check SM-3 Pointer to buffer not reset to beginning after line read SM-4 Typo prevents a size check from being performed SM-5, prescan Input byte set to 0xff cast to minus one error code SM-6, ttflag Negative index passes size check but causes underflow SM-7 Size for strncpy read from packet header but not checked FTP-1 Several strcpy calls without bounds check FTP-2 Wrong size check inside if > should really be >= FTP-3 Several unchecked strcpy and strcat calls 11/02/

22 memcpy copy memory block of n bytes sprintf() output printed to a buffer strncpy string copy up to n bytes strcpy string copy strcat string append from Wikipedia strcpy can be dangerous because if the string to be copied is too long to fit in the destination buffer, it will overwrite adjacent memory, causing unpredictable behavior. Usually the program will simply cause a segmentation fault when this occurs, but a skilled attacker can use such a buffer overflow to crack into a system (see computer security ). 11/02/2008 Dr Andy Brooks 22

23 Buffer overflow characteristics In each of the 14 smaller model programs, there were often repeated buffer overflows of the same buffer with similar characteristics. For identical buffer overflows, the characteristics were counted only once and not separately. 11/02/2008 Dr Andy Brooks 23

24 Table 3 Buffer overflow characteristics Characteristic Out-of-bounds Type Location Scope Container Index or limit Access Buffer alias Control flow Surrounding loops Input taint Observed values 93% upper, 7% lower 64% character arrays, 36% u_char arrays 73% stack, 16% bss, 7% heap, 4% data 43% inter-procedural, 52% same function (intra-procedural), 5% global buffer 93% none, 7% union 64% none, 22% variable, 7% linear exp., 7% buffer contents 56% C function (memcpy,strcpy), 26% pointer, 11% index, 7% double de-reference 52% alias, 34% no alias, 14% alias of an alias 29% none, 49% if statement, 22% switch 46% none, 42% while, 5% for, 7% nested 64% internet packets, 22% directory functions (e.g. getcwd), 7% file inputs, 7% argc/arg (CLI arguments) 11/02/2008 Dr Andy Brooks 24

25 Access Many (56%) of the buffer overflows are caused by incorrect use of a string manipulation function (e.g. strcpy, memcpy), and the rest are caused by direct accesses using pointers or an index. Alternative, safer versions of string manipulation functions came into being... 11/02/2008 Dr Andy Brooks 25

26 5. Test Procedures Source code annotations were not used. Flags were set based on advice in the documentation and from tool developers. Use high, medium, low settings? The 5 static analysis tools were run on 14 pairs of BAD and OK smaller model programs. Each BAD progam had one or more lines that could overflow a buffer. The OK program employed the developers patch. This sometimes resulted in a different number of BAD and OK lines. 11/02/2008 Dr Andy Brooks 26

27 5. Test Procedures Some of the tools provided a line number for each warning and this was used to count detections and false alarms. Otherwise the name and other buffer information was used. Only warnings for lines labeled BAD or OK were counted as detections or false alarms BAD OK /02/2008 Dr Andy Brooks 27

28 confused/ráðvilltur 6. Results C(d) Number of times a tool detected a line labelled BAD on the model program (true positives). C(f) Number of times a tool detected a line labelled OK on the model program (false positives). C(df) Number of times a tool was confused a true positive paired with a false positive on the patched code. T(d) Total number of true positives possible for a model program. T(f) Total number of false positives possible for a model program. 11/02/2008 Dr Andy Brooks 28

29 probability is the same as relative frequency líkindi er sama sem hlutfallslegtíðni 6. Results P(A) = 1 P(A) P(d) = C(d)/T(d) Probability of true positive. P(f) = C(f)/T(f) Probability of false positive. P( f d) = 1 C(df)/C(d) Probability of discrimination Probability of no confusion on OK code given a detection on BAD code. 11/02/2008 Dr Andy Brooks 29

30 Table 4 Detection and false positive rates Tool P(d) P(f) P( f d) PolySpace 0,87 0,5 0,37 Splint 0,57 0,43 0,30 Boon 0,05 0,05 - Archer 0, Uno /02/2008 Dr Andy Brooks 30

31 Receiver Operating Characteristic Figure 4. ROC-type plot Where you want to be: 11/02/2008 Dr Andy Brooks 31

32 Figure 4. ROC-type plot The diagonal line is the random guess line. Only PolySpace and Splint have points above the line. The error bars are... plus or minus two standard deviations for random guessing systems with false alarm rates equal to those observed for Splint and PolySpace. Only PolySpace is statistically significantly different from a random guessing system. 11/02/2008 Dr Andy Brooks 32

33 6. Results PolySpace and Splint had good detection rates for buffer overflows. Three tools had very poor detection rates for buffer overflows. False positive rates are however high for PolySpace and Splint. Discrimination probabilities P( f d) ideally should be 1, but are less than 0,4 for PolySpace and Splint. This means that more than half the time, these tools continue to signal a buffer overflow after it has been patched. 11/02/2008 Dr Andy Brooks 33

34 6. Results More than half the time, PolySpace and Splint would continue to warn of a buffer overflow after it has been patched. Continuing to generate false positives this way greatly undermines the useability of these two tools. PolySpace and Splint also produced many warnings for the OK model programs not associated with lines marked OK. PolySpace produced one warning every 12 lines of code and Splint produced one warning every 46 lines of code. Warning rates are unacceptably high 11/02/2008 Dr Andy Brooks 34

35 7. Discussion The results are promising because some static analysis tools would have detected in-the-wild buffer overflows. They are disappointing because false alarm rates are high and discrimination poor. 11/02/2008 Dr Andy Brooks 35

36 7. Discussion The results should not be generalised to other software. The false positive rates were not verified. Some false positives seemed genuine. the OK models were too complicated to warrant against out-of bounds accesses by inspection I just cannot be sure this code is OK... 11/02/2008 Dr Andy Brooks 36