Static Detection of Buffer Overrun In C Code

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

2. Introduction • “A First Step Towards Automated Detection of Buffer Overrun Vulnerabilities” • David Wagner • Jeffery S. Foster • Eric Brewer • Alexander Aiken • University of California, Berkeley

3. Topics of Discussion • The Buffer Overrun Problem • Static Analysis through Constraints • Experience with the tool • Performance • Limitations of the tool • Conclusions • Future Directions

4. Buffer Overrun • The problem? Lots of unsafe legacy C code! • The fingerd attack in 1988 is a prime example • C is inherently unsafe • Array and pointer references are not automatically bounds-checked • standard C library is unsafe

5. Standard C Library is Unsafe • Inconsistencies in the library • strncpy(dst, src, sizeof(dst)) is correct • strncat(dst, src, sizeof(dst) is incorrect • Encouragement of one-off errors • strncat(dst, src, sizeof(dst) - strlen(dst) - 1) is correct • But -1 is often overlooked

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

7. Static Analysis through Constraints • Why static analysis? • Runtime testing may miss problems in code paths not followed in ordinary execution • Opportunity to eliminate problems proactively • Fundamental Ideas • C Strings treated as an abstract data type • Buffers modeled as pairs of integer ranges

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

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

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

11. 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) Constraint Generation Example

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

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

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

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

16. Limitations: Correctness • false alarms • 44 Probable warnings generated for Sendmail 8.9.3 with only 4 being actual one-off bugs • For comparison, there were 695 call sites to potentially unsafe string operations • Reduce these by adding flow-sensitive or context-sensitive analysis • - performance degradation • + 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 • false negatives • pointer aliasing and primitive pointer operations are ignored • A known Sendmail 8.7.5 overrun bug was missed due to this • But of 10 known fixed overrun Sendmail 8.7.5 bugs, tool missed only that one • How 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 • Useful for review of legacy code • gives pointers to reviewers of areas to concentrate on • An improvement of 15X over grep (Sendmail 8.9.3) • Found some previously undocumented buffer overrun vulnerabilities in “reviewed” code (Linux nettools)

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

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