Uncovering Undefined Behavior 1 Overview

In this project we study the effects of undefined behavior in open source software and its ability to cause unstable code to be optimized out by modern compilers. Given the sheer number of software systems that contain such errors, with about 50% of Debian packages reporting over 80,000 different warnings, we attempted to begin the process of filtering through these results. With the help of Stack[3], we analyzed 85 packages, from Debian and other locations, and submitted a total of 18 patches, of which 8 have been accepted thus far, with the rest pending approval. This paper presents a case study into the common mis-practices of many developers and has helped us develop a rule-of-thumb heuristic as to which types of bugs are more or less likely to be vulnerabilities. In section 2 we review our working threat model and the security implications of undefined behavior, in section 3 we break down the observed bugs into a number of different categories that loosely correspond to the types of bugs Stack can detect, and in section 4 we wrap up and discuss future areas of research. 2 Security Overview Threat Model When accessing the security implications of undefined behavior we assume that an attacker has complete knowledge of the source code. Any optimization unsafe bugs that exist are known to the attacker, and are able to be exploited if possible. Threats Undefined behavior can lead to a number of common security vulnerabilities. In our case study of undefined behavior we observe pointer overflows, buffer overflows, integer overflows, uninitialized data, null pointer dereferences, and infinite loops. In a recent case study from 2010 to mid 2011 [2] of the Linux kernel, these types of errors have been shown to account for up to 70% of the CVE reports. As compilers increasingly take advantage of undefined behavior Classification of Unstable Code Generally, the bugs we found due to unstable code fell into several main categories. First, null pointer dereferences were the most common type of bug signaled by Stack but did not alter correctness. Mixed in with these null pointer dereferences were actual programmer errors due to accidentally not dereferencing pointers for which they wanted their value. Second, signed integer operation overflow checks were another common source of developer misconception. Thirdly, there were pointer overflow bugs. And finally, there were a class of miscellaneous bugs related to division by zero, buffer overflow by one, and shift left and right overflow. Null Pointer Dereference The most common type of warning given by Stack was that of the null pointer dereference. As the C standard states [1], dereferencing a null pointer is undefined, so modern compilers use this standard to predict all previously dereferenced pointers are already non-null. Often times, programmers write redundant checks to verify something is nonnull