1. Static Detection of Buffer Overrun In C Code Lucas Silacci CSE 231 Spring 2000 University of California San Diego

2. Introduction z“A First Step Towards Automated Detection of Buffer Overrun Vulnerabilities” zDavid Wagner zJeffery S. Foster zEric Brewer zAlexander Aiken zUniversity of California, Berkeley

3. Topics of Discussion zThe Buffer Overrun Problem zStatic Analysis through Constraints zExperience with the tool zPerformance zLimitations of the tool zConclusions zFuture Directions

4. Buffer Overrun zThe problem? Lots of unsafe legacy C code! yThe fingerd attack in 1988 is a prime example zC is inherently unsafe zArray and pointer references are not automatically bounds-checked zstandard C library is unsafe

5. Standard C Library is Unsafe zInconsistencies in the library ystrncpy(dst, src, sizeof(dst)) is correct ystrncat(dst, src, sizeof(dst) is incorrect zEncouragement of one-off errors ystrncat(dst, src, sizeof(dst) - strlen(dst) - 1) is correct yBut -1 is often overlooked

6. CERT Advisories zAs much as 50% of CERT-reported vulnerabilities are buffer overrun related

7. Static Analysis through Constraints zWhy static analysis? yRuntime testing may miss problems in code paths not followed in ordinary execution yOpportunity to eliminate problems proactively zFundamental Ideas yC Strings treated as an abstract data type yBuffers modeled as pairs of integer ranges

8. Constraint Language zalloc(str): set of possible number of bytes allocated for string str zlen(str): set of possible lengths of string str zsafety condition: alloc(str) <= len(str)

9. Safety Condition cont. zFor two ranges: alloc(str) = [a, b]; len(str) = [c, d] zb <= c str never overflows its buffer za > d str always overflows its buffer zranges overlap an overflow cannot be ruled out

10. Constraint Generation zGenerate an integer range constraint for each line of C code  Constraints take the form of X  Y where X, Y are range variables zexamples:  char dst[n]; n  alloc(dst)  sprintf(dst, “%s”, src); len(src)  len(dst)  fgets(str, n,...); [1, n]  len(str)

11. Constraint Generation Example Source Code: char buf[128]; while (fgets(buf, 128, stdin)) { if (!strchr(buf, ‘\n’)) { char error[128]; sprintf(error, “Line too long: %s\n”, buf); die(error); }... } The Focus is on primitive string operations! Constraints: [128, 128]  alloc(buf) [1, 128]  len(buf) [128, 128]  alloc(error) len(buf) + 16  len(error)

12. Constraint Solver zEfficient algorithm for finding a bounding box solution to a system of constraints ygives bounds on ranges of variables, but can’t give any info on relationship between them zflow-insensitive analysis ysacrifices precision for scalability, efficiency and ease of implementation

13. Experience: Linux nettools zThe tool found buffer overrun problems that were previously undiscovered in a manual audit in 1996: ya library blindly trusting the length returned by DNS lookups yseveral unchecked strcpy()’s that could cause buffer overrun by spoofing ya routine blindly copying the result of getnetbyname() into a fixed-size buffer

14. Experience: Sendmail 8.7.5 zRun on an older version of Sendmail to compare against problems found by hand auditing zFound a number of possible buffer overrun errors that were fixed in later versions (8.7.6 & 8.8.6)

15. Performance zStatic Analysis Time yperformance is “sub-optimal but usable” y15 minutes on a fast Pentium III for Sendmail (32k lines of C code) zGreatly overshadowed by time required to examine all warnings by hand zscalability is in question as they “have no experience with very large applications”

16. Limitations: Correctness zfalse alarms y44 Probable warnings generated for Sendmail 8.9.3 with only 4 being actual one- off bugs yFor comparison, there were 695 call sites to potentially unsafe string operations zReduce these by adding flow-sensitive or context-sensitive analysis y- performance degradation y+ fewer false alarms means less user intervention

17. Flow-Insensitive Example strcpy is not really reached unless it is safe: if (sizeof(dst) < strlen(src) + 1) break; strcpy(dst, src); Incorrectly flagged as a possible overrun since the analysis is flow-insensitive!

18. Limitations: Completeness zfalse negatives ypointer aliasing and primitive pointer operations are ignored xA known Sendmail 8.7.5 overrun bug was missed due to this yBut of 10 known fixed overrun Sendmail 8.7.5 bugs, tool missed only that one zHow do you know you missed an error?

19. Pointer Aliasing Example A 13-byte string is copied into the 10-byte buffer t: char s[20], *p, t[10]; strcpy(s, “Hello”); p = s + 5; strcpy(p, “ world!”); strcpy(t, s); This is not caught due to pointer aliasing

20. Conclusions zUseful for review of legacy code ygives pointers to reviewers of areas to concentrate on xAn improvement of 15X over grep (Sendmail 8.9.3) yFound some previously undocumented buffer overrun vulnerabilities in “reviewed” code (Linux nettools)

21. Conclusions (cont.) zStatic checking of code before deployment ylacks performance degradation of most run- time checkers yprogram verification systems typically require programmers to annotate code ycurrently requires much manual intervention to sort out real problems from false alarms

22. Future Directions zAddition of flow-sensitive analysis yExpected removal of ~48% of false alarms zAddition of flow- and context-sensitive analysis with linear invariants and pointer analysis yExpected removal of ~95% of false alarms zBoth would have some obvious performance impact