1 / 22

Static Detection of Buffer Overrun In C Code

Static Detection of Buffer Overrun In C Code. Lucas Silacci CSE 231 Spring 2000 University of California San Diego. Introduction. “A First Step Towards Automated Detection of Buffer Overrun Vulnerabilities” David Wagner Jeffery S. Foster Eric Brewer Alexander Aiken

kiaria
Download Presentation

Static Detection of Buffer Overrun In C Code

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related