Appeared in Proceedings of the 34th International Conference on Software Engineering (ICSE), Zurich, Switzerland, June 2012.
Understanding Integer Overflow in C/C++
Will Dietz,∗ Peng Li,† John Regehr,† and Vikram Adve∗ ∗Department of Computer Science University of Illinois at Urbana-Champaign {wdietz2,vadve}@illinois.edu †School of Computing University of Utah {peterlee,regehr}@cs.utah.edu
Abstract—Integer overflow bugs in C and C++ programs Detecting integer overflows is relatively straightforward are difficult to track down and may lead to fatal errors or by using a modified compiler to insert runtime checks. exploitable vulnerabilities. Although a number of tools for However, reliable detection of overflow errors is surprisingly finding these bugs exist, the situation is complicated because not all overflows are bugs. Better tools need to be constructed— difficult because overflow behaviors are not always bugs. but a thorough understanding of the issues behind these errors The low-level nature of C and C++ means that bit- and does not yet exist. We developed IOC, a dynamic checking tool byte-level manipulation of objects is commonplace; the line for integer overflows, and used it to conduct the first detailed between mathematical and bit-level operations can often be empirical study of the prevalence and patterns of occurrence quite blurry. Wraparound behavior using unsigned integers of integer overflows in C and C++ code. Our results show that intentional uses of wraparound behaviors are more common is legal and well-defined, and there are code idioms that than is widely believed; for example, there are over 200 deliberately use it. On the other hand, C and C++ have distinct locations in the SPEC CINT2000 benchmarks where undefined semantics for signed overflow and shift past overflow occurs. Although many overflows are intentional, a bitwidth: operations that are perfectly well-defined in other large number of accidental overflows also occur. Orthogonal languages such as Java. C/C++ programmers are not always to programmers’ intent, overflows are found in both well- defined and undefined flavors. Applications executing undefined aware of the distinct rules for signed vs. unsigned types in C, operations can be, and have been, broken by improvements in and may na¨ıvely use signed types in intentional wraparound compiler optimizations. Looking beyond SPEC, we found and operations.1 If such uses were rare, compiler-based overflow reported undefined integer overflows in SQLite, PostgreSQL, detection would be a reasonable way to perform integer error SafeInt, GNU MPC and GMP, Firefox, GCC, LLVM, Python, detection. If it is not rare, however, such an approach would BIND, and OpenSSL; many of these have since been fixed. Our results show that integer overflow issues in C and C++ be impractical and more sophisticated techniques would be are subtle and complex, that they are common even in mature, needed to distinguish intentional uses from unintentional widely used programs, and that they are widely misunderstood ones. by developers. Although it is commonly known that C and C++ programs Keywords-integer overflow; integer wraparound; undefined contain numerical errors and also benign, deliberate use behavior of wraparound, it is unclear how common these behaviors are and in what patterns they occur. In particular, there is I.INTRODUCTION little data available in the literature to answer the following Integer numerical errors in software applications can questions: be insidious, costly, and exploitable. These errors include 1) How common are numerical errors in widely-used overflows, underflows, lossy truncations (e.g., a cast of an C/C++ programs? to a in C++ that results in the value being int short 2) How common is use of intentional wraparound op- changed), and illegal uses of operations such as shifts (e.g., erations with signed types—which has undefined shifting a value in C by at least as many positions as its behavior—relying on the fact that today’s compilers bitwidth). These errors can lead to serious software failures, may compile these overflows into correct code? We e.g., a truncation error on a cast of a floating point value to refer to these overflows as “time bombs” because they a 16-bit integer played a crucial role in the destruction of remain latent until a compiler upgrade turns them into Ariane 5 flight 501 in 1996. These errors are also a source observable errors. of serious vulnerabilities, such as integer overflow errors in 3) How common is intentional use of well-defined OpenSSH [1] and Firefox [2], both of which allow attackers to execute arbitrary code. In their 2011 report MITRE places 1In fact, in the course of our work, we have found that even experts integer overflows in the “Top 25 Most Dangerous Software writing safe integer libraries or tools to detect integer errors are not always Errors” [3]. fully aware of the subtleties of C/C++ semantics for numerical operations.
c 2012 IEEE. Personal use of this material is permitted. However, permission to reprint/republish this material for advertising or promotional purposes or for creating new collective works for resale or redistribution to servers or lists, or to reuse any copyrighted component of this work in other works must be obtained from the IEEE. wraparound operations on unsigned integer types? Table I EXAMPLESOF C/C++ INTEGER OPERATIONS AND THEIR RESULTS Although there have been a number of papers on tools Expression Result to detect numerical errors in C/C++ programs, no previous UINT_MAX+1 0 work we know of has explicitly addressed these questions, or LONG_MAX+1 undefined contains sufficient data to answer any of them. INT_MAX+1 undefined The closest is SHRT_MAX+1 SHRT_MAX+1 if INT_MAX>SHRT_MAX, Brumley et al.’s work [4], which presents data to motivate the otherwise undefined goals of the tool and also to evaluate false positives (invalid char c = CHAR_MAX; c++ varies1 2 error reports) due to intentional wraparound operations. -INT_MIN undefined (char)INT_MAX commonly -1 As discussed in Section V, that paper only tangentially 1<<-1 undefined addresses the third point above. We study all of these 1<<0 1 questions systematically. 1<<31 commonly INT_MIN in ANSI C and C++98; undefined in C99 and C++112,3 This paper makes the following primary contributions. 1<<32 undefined3 First, we developed Integer Overflow Checker (IOC), an 1/0 undefined open-source tool that detects both undefined integer behav- INT_MIN%-1 undefined in C11, otherwise undefined in practice iors as well as well-defined wraparound behaviors in C/C++ 1 2 The question is: Does c get “promoted” to int before being incre- programs. IOC is an extension of the Clang compiler for mented? If so, the behavior is well-defined. We found disagreement C/C++ [5]. Second, we present the first detailed, empirical between compiler vendors’ implementations of this construct. study—based on SPEC 2000, SPEC 2006, and a number 2 Assuming that the int type uses a two’s complement representation 3 Assuming that the int type is 32 bits long of popular open-source applications—of the prevalence and patterns of occurrence of numerical overflows in C/C++ programs. Part of this study includes a manual analysis of a cannot simply distinguish errors from benign operations by large number of intentional uses of wraparound in a subset checking rules from the ISO language standards. Rather, of the programs. Third, we used IOC to discover previously tools will have to use highly sophisticated techniques and/or unknown overflow errors in widely-used applications and rely on manual intervention (e.g., annotations) to distinguish libraries, including SQLite, PostgreSQL, BIND, Firefox, intentional and unintentional overflows. OpenSSL, GCC, LLVM, the SafeInt library, the GNU MPC and GMP libraries, Python, and PHP. A number of these II.OVERFLOW IN C AND C++ have been acknowledged and fixed by the maintainers (see Mathematically, n-bit two’s complement arithmetic is Section IV). congruent, modulo 2n, to n-bit unsigned arithmetic for The key findings from our study of overflows are as addition, subtraction, and the n least significant bits in follows: First, all four combinations of intentional and multiplication; both kinds of arithmetic “wrap around” at unintentional, well-defined and undefined integer overflows multiples of 2n. On modern processors, integer overflow is occur frequently in real codes. For example, the SPEC equally straightforward: n-bit signed and unsigned opera- CINT2000 benchmarks had over 200 distinct occurrences tions both have well-defined behavior when an operation of intentional wraparound behavior, for a wide range of overflows: the result wraps around and condition code bits different purposes. Some uses for intentional overflows are are set appropriately. In contrast, integer overflows in C/C++ well-known, such as hashing, cryptography, random number programs are subtle due to a combination of complex generation, and finding the largest representable value for and counter-intuitive rules in the language standards, non- a type. Others are less obvious, e.g., inexpensive floating standards-conforming compilers, and the tendency of low- point emulation, signed negation of INT_MIN, and even level programs to rely on non-portable behavior. Table I ordinary multiplication and addition. We present a detailed contains some C/C++ expressions illustrating cases that arise analysis of examples of each of the four major categories in practice. There are several issues; to clarify them we make of overflow. Second, overflow-related issues in C/C++ are a top-level distinction between well-defined (albeit perhaps very subtle and we find that even experts get them wrong. non-portable) and undefined operations. For example, the latest revision of Firefox (as of Sep 1, 2011) contained integer overflows in the library that was A. Well-Defined Behaviors designed to handle untrusted integers safely in addition to overflows in its own code. More generally, we found very Some kinds of unsigned integer arithmetic uses well- few mature applications that were completely free of integer defined and portable wraparound behavior, with two’s numerical errors. This implies that there is probably little complement semantics [6]. Thus, as Table I indicates, hope of eliminating overflow errors in large code bases UINT_MAX+1 must evaluate to zero in every conforming without sophisticated tool support. However, these tools C and C++ implementation. nOf course, even well-defined semantics can lead to logic errors, for example if a developer 2IOC is available at http://embed.cs.utah.edu/ioc/ na¨ıvely assumes that x + 1 is larger than x.
2 Listing 1. Source for overflow.c referred to in the text break them in non-obvious and not necessarily consistent 1 int foo (int x) { 2 return ( x+1 ) > x; ways. 3 } 2) Time Bombs: Undefined behavior also leads to time 4 5 int main (void) { bombs: code that works under today’s compilers, but breaks 6 printf ("%d\n", ( INT_MAX+1 ) > INT_MAX); unpredictably in the future as optimization technology im- 7 printf ("%d\n", foo(INT_MAX)); 8 return 0; proves. The Internet is rife with stories about problems 9 } caused by GCC’s ever-increasing power to exploit signed overflows. For example, in 2005 a principal PostgreSQL Many unsigned integer overflows in C and C++ are well- developer was annoyed that his code was broken by a recent defined, but non-portable. For example 0U-1 is well-defined version of GCC:5 and evaluates to UINT_MAX, but the actual value of that It seems that gcc is up to some creative reinterpre- constant is implementation defined: it can be relied upon, but tation of basic C semantics again; specifically, you only within the context of a particular compiler and platform. can no longer trust that traditional C semantics of Similarly, the int type in C99 is not required to hold values integer overflow hold ... in excess of 32,767, nor does it have to be based on a two’s This highlights a fundamental and pervasive misunderstand- complement representation. ing: the compiler was not “reinterpreting” the semantics but B. Undefined Behaviors rather was beginning to take advantage of leeway explicitly provided by the C standard. Some kinds of integer overflow are undefined, and these In Section IV-E we describe a time bomb in SafeInt [7]: a kinds of behavior are especially problematic. According to library that is itself intended to help developers avoid unde- the C99 standard, undefined behavior is fined integer overflows. This operation, until recently, was “behavior, upon use of a non-portable or erroneous reliably compiled by GCC (and other compilers) into code program construct or of erroneous data, for which that did not have observable errors. However, the upcoming this International Standard imposes no require- version of GCC (4.7) exposes the error, presumably because ments.” it optimizes the code more aggressively. We discovered this 3 In Internet parlance: error using IOC and reported it to the developers, who fixed “When the compiler encounters [a given undefined it within days [8]. construct] it is legal for it to make demons fly out 3) Illusion of Predictability: Some compilers, at some of your nose.” optimization levels, have predictable behavior for some Our experience is that many developers fail to appreciate the undefined operations. For example, C and C++ compil- full consequences of this. The rest of this section examines ers typically give two’s complement semantics to signed these consequences. overflow when aggressive optimizations are disabled. It is, 1) Silent Breakage: A C or C++ compiler may exploit however, unwise to rely on this behavior, because it is not undefined behavior in optimizations that silently break a portable across compilers or indeed across different versions program. For example, a routine refactoring of Google’s of the same compiler. Native Client software accidentally caused 1<<32 to be 4) Informal Dialects: Some compilers support stronger evaluated in a security check.4 The compiler—at this point semantics than are mandated by the standard. For example, under no particular obligation—simply turned the safety both GCC and Clang (an LLVM-based C/C++/Objective-C check into a nop. Four reviewers failed to notice the resulting compiler) support a -fwrapv command line flag that forces vulnerability. signed overflow to have two’s complement behavior. In fact, Another illuminating example is the code in Listing 1. the PostgreSQL developers responded to the incident above In this program, the same computation ((INT_MAX+1) by adding -fwrapv to their build flags. They are now, in >INT_MAX) is performed twice with two different idioms. effect, targeting a non-standard dialect of C. Recent versions of GCC, LLVM, and Intel’s C compiler, 5) Non-Standard Standards: Some kinds of overflow invoked at the -O2 optimization level, all print a 0 for the have changed meaning across different versions of the first value (line 6) and a 1 for the second (line 7). In other standards. For example, 1<<31 is implementation-defined words, each of these compilers considers INT_MAX+1 to in ANSI C and C++98, while being explicitly undefined be both larger than INT_MAX and also not larger, at the by C99 and C11 (assuming 32-bit ints). Our experience is same optimization level, depending on incidental structural that awareness of this particular rule among C and C++ features of the code. The point is that when programs exe- programmers is low. cute undefined operations, optimizing compilers may silently A second kind of non-standardization occurs with con- structs such as INT_MIN%-1 which is—by our reading—well 3http://catb.org/jargon/html/N/nasal-demons.html 4http://code.google.com/p/nativeclient/issues/detail?id=245 5http://archives.postgresql.org/pgsql-hackers/2005-12/msg00635.php
3 IOC B. Overflow Checks Finding overflows in shift operations is straightforward: Instrumentation Runtime operand values are bounds-checked and then, if the checks pass, the shift is performed. Checking for overflow in arith- metic operations is trickier; the problem is that a checked n- Source Checked IR Executable bit addition or subtraction requires n+1 bits of precision and Front End Back End Execution a checked n-bit multiplication requires 2n bits of precision. Finding these extra bits can be awkward. There are basically Figure 1. Architecture of IOC three ways to detect overflow for an operation on two signed integers s1 and s2. defined in ANSI C, C99, C++98, and C++11. However, we 1) Precondition test. It is always possible to test whether are not aware of a C or C++ compiler that reliably returns an operation will wrap without actually performing the the correct result, zero, for this expression. The problem operation. For example, signed addition will wrap if is that on architectures including x86 and x86-64, correctly and only if this expression is true: handling this case requires an explicit check in front of every ((s > 0) ∧ (s > 0)∧(s > (INT_MAX − s )))∨ % operation. The C standards committee has recognized the 1 2 1 2 problem and C11 explicitly makes this case undefined. ((s1 < 0) ∧ (s2 < 0)∧(s1 < (INT_MIN − s2)))
III.TOOL DESIGNAND IMPLEMENTATION In pseudocode: IOC, depicted in Fig. 1, has two main parts: a compile- if (!precondition) then time instrumentation transformation and a runtime handler. call failure handler The transformation is a compiler pass that adds inline endif numerical error checks; it is implemented as a ∼1600 LOC result = s1 op s2 extension to Clang [5], the C/C++ frontend to LLVM [9]. 2) CPU flag postcondition test. Most processors contain IOC’s instrumentation is designed to be semantically trans- hardware support for detecting overflow: following parent for programs that conform to the C or C++ language execution of an arithmetic operation, condition code standards, except in the case where a user requests additional flags are set appropriately. In the general case, it is checking for conforming but error-prone operations, e.g., problematic to inspect processor flags in portable code, wraparound with unsigned integer types. The runtime library but LLVM supports a number of intrinsic functions is linked into the compiler’s output and handles overflows where, for example, an addition operation returns a as they occur; it is ∼900 lines of C code. structure containing both the result and an overflow flag. The LLVM backends, then, emit processor-specific A. Where to Put the Instrumentation Pass? code that accesses the proper CPU flag. In pseudocode: The transformation operates on the Abstract Syntax Tree (result, flag) = s1 checked_op s2 (AST) late in the Clang front end—after parsing, type- if (flag) then checking, and implicit type conversions have been per- call failure handler formed. This is an appropriate stage for inserting checks endif because full language-level type information is available, but the compiler has not yet started throwing away useful 3) Width extension postcondition test. If an integer information as it does during the subsequent conversion into datatype with wider bitwidth than the values being the flat LLVM intermediate representation (IR). operated on is available, overflow can be detected in In a previous iteration of IOC we encoded the required a straightforward way by converting s1 and s2 into high-level information into the IR (using IR metadata), the wider type, performing the operation, and checking allowing the transformation to be more naturally expressed whether the result is in bounds with respect to the as a compiler pass. Unfortunately, this proved to be un- original (narrower) type. In pseudocode: reliable and unnecessarily complicated, due to requiring a result = extend(s1) op extend(s2) substantial amount of C-level type information in the IR if (result < MIN || result > MAX) then in order to support a correct transformation. The original call failure handler transformation was further complicated by the lack of a endif one-to-one mapping between IR and AST nodes. Also, some IOC supports both the precondition test and the CPU flag important operations (such as signed to unsigned casts) don’t postcondition test; width extension seemed unlikely to be exist at the IR level. In short, it is much less error-prone to better than these options due to the expense of emulating 64- do the instrumentation in the frontend where all the required bit and 128-bit operations. Initially we believed that the CPU information is naturally available. flag postcondition checks would be far more efficient but this
4 proved not to be the case. Rather, as shown in Section III-D, Table II using the flag checks has an uneven effect on performance. TAXONOMY OF INTEGER OVERFLOWS IN C AND C++ WITH REFERENCESTODETAILEDDISCUSSIONOFEXAMPLES The explanation can be found in the interaction between the overflow checks and the compiler’s optimization passes. The undefined behavior defined behavior precondition test generates far too many operations, but they e.g. signed overflow, e.g. unsigned wrapround, shift error, signed wraparound are operations that can be aggressively optimized by LLVM. divide by zero with -fwrapv On the other hand, the LLVM intrinsics supporting the flag- intentional Type 1: Type 2: based postcondition checks are recognized and exploited design error, no error, may be a “time bomb” but may not be portable by relatively few optimization passes, causing much of § IV-C3, IV-C9 § IV-C2, IV-C5, IV-C8 the potential performance gain due to this approach to be unintentional Type 3: Type 4: unrealized. implementation error, implementation error may be a “time bomb” C. Runtime Library § IV-C4 § IV-C1, IV-C6 To produce informative error messages, IOC logs the used the median runtime. We configured the fault handler to source-code location corresponding to each inserted check, return immediately instead of logging overflow behaviors. including the column number where the operator appeared. Thus, these measurements do not include I/O effects due (Operating on the AST instead of the LLVM IR makes to logging, but they do include the substantial overhead of such logging possible.) Thus, users can disambiguate, for marshaling the detailed failure information that is passed to example, which shift operator overflowed in a line of code the fault handler. containing multiple shift operators. Also in service of For undefined behavior checking using precondition readable error messages, IOC logs the types and values of checks, slowdown relative to the baseline ranged from the arguments passed to the operator; this is important for −0.5%–191%. In other words, from a tiny accidental operators with multiple modes of failure, such as shift. For speedup to a 3X increase in runtime. The mean slowdown example, an error we found in OpenSSL was reported as: was 44%. Using flag-based postcondition checks, slowdown
5 Listing 2. Well-defined but incorrect guard for memcpy in 164.gzip 1 /* (this test assumes unsigned comparison) */ 2 if ( w - d >= e) Table III 1 3 { INTEGER WRAPAROUNDS REPORTED IN SPEC CINT2000 4 memcpy(slide + w, slide + d, e); Name Location2 Op3 Description 5 w += e; 164.gzip bits.c(136:18) +u Bit manipulation 6 d += e; 164.gzip bits.c(136:28) −u Bit manipulation 7 } 164.gzip deflate.c(540:21) −u Unused 164.gzip inflate.c(558:13) −u Bit manipulation 164.gzip inflate.c(558:22) −u Bit manipulation software containing these behaviors. Only Type 2 overflows 164.gzip inflate.c(566:15) −u Incorrect memcpy guard (Listing 2) do not introduce numerical errors into carefully written 164.gzip trees.c(552:25) +u Type promotion 164.gzip trees.c(990:38) −u Type promotion C/C++ software. Using IOC, we have found examples of 175.vpr route.c(229:19) −u Hash 4 175.vpr util.c(463:34) ∗u RNG (Listing 3) software errors of Types 1, 3, and 4, as well as correct uses 4 175.vpr util.c(463:39) +u RNG 4 of Type 2. The section numbers in the table are forward 175.vpr util.c(484:34) ∗u RNG 4 references to discussions of bugs in the next section. We 175.vpr util.c(484:39) +u RNG found many additional examples of each type of error, but 176.gcc combine.c × 6 −s Find INT_MAX (Listing 4) 176.gcc cse.c × 5 +u Hash lack space to discuss them in detail. 176.gcc expmed.c × 15 ±u,s Bit manipulation n 176.gcc expmed.c(2484:13) ∗u Inverse of x mod 2 n 176.gcc expmed.c(2484:18) −u Inverse of x mod 2 n C. Wraparound and Overflow in SPEC CINT 2000 176.gcc expmed.c(2484:21) ∗u Inverse of x mod 2 176.gcc insn-emit.c(3613:5) +u Range check To investigate the prevalence of, and use-cases for, over- 176.gcc loop.c(1611:19) ∗s Cost calculation bug (Listing 5) flows and wraparounds, we examined SPEC CINT2000 in 176.gcc m88k.c(127:44) −u Bit manipulation (Listing 6) 176.gcc m88k.c(128:20) +u Bit manipulation detail. The SPEC benchmark suites each contain a care- 176.gcc m88k.c(128:20) −u Bit manipluation fully selected set of C and C++ programs, designed to be 176.gcc m88k.c(888:13) +u Range check 176.gcc m88k.c(1350:38) +u Range check representative of a wide range of real-world software (and 176.gcc m88k.c(2133:9) +u Range check many like GCC, bzip2, and povray, are taken from widely 176.gcc obstack.c(271:49) −u Type promotion artifact 176.gcc real.c(1909:35) −u Emulating addition used applications). Moreover, since they are primary per- 176.gcc real.c(2149:18) ∗s Overflow check formance benchmarks for both compilers and architectures, 176.gcc rtl.c(193:16) +u Allocation calc bug (Listing 7) 176.gcc rtl.c(193:16) ∗u Allocation calc bug these benchmarks have been compiled and tested with most 176.gcc rtl.c(216:19) ∗u Allocation calc bug optimizing compilers, making them especially good case 176.gcc rtl.c(216:5) +u Allocation calc bug 176.gcc stor-layout.c(1040:7) −s Find largest sint studies. 176.gcc tree.c(1222:15) ∗s Hash We ran the SPEC benchmarks’ “ref” data sets. Using IOC, 176.gcc tree.c(1585:37) −s Bit manipulation 176.gcc varasm.c(2255:15) ∗s Hash we investigated every addition, subtraction, multiplication, 186.crafty evaluate.c(594:7) −u Bit manipulation and division overflow in an attempt to understand what it 186.crafty evaluate.c(595:7) −u Bit manipulation 186.crafty iterate.c(438:16) ∗s Statistic bug (100*a/(b+1)) 4 is that developers are trying to accomplish when they put 186.crafty utility.c(813:14) +u RNG overflows into their code. 197.parser and.c × 6 +u,s Hash 197.parser fast-match.c(101:17) +u Hash Our findings are shown in Table III and described below. 197.parser fast-match.c(101:8) +s Hash This benchmark suite consists of 12 medium-sized programs 197.parser parse.c × 10 +u,s Hash 197.parser prune.c × 7 +u,s Hash (2.5–222 KLOC), eight of which executed integer overflows 197.parser xalloc.c(68:40) ∗u Compute SIZE_MAX >> 1 (Listing 8) while running on their reference input data sets. 197.parser xalloc.c(70:19) +u Compute SIZE_MAX >> 1 253.perlbmk hv.c × 7 ∗u Hash Note: Real C code is messy. We have cleaned up the 253.perlbmk md5c.c × 68 +u Hash SPEC code examples slightly when we deemed this to 253.perlbmk pp.c(1958:14) −u Missing cast 253.perlbmk pp.c(1971:6) +u Missing cast improve readability and to not change the sense of the code. 253.perlbmk regcomp.c(353:26) +s Unused 1) 164.gzip: IOC reported eight wraparounds in this 253.perlbmk regcomp.c(462:21) +s Unused 253.perlbmk regcomp.c(465:21) +s Unused benchmark, all using well-defined unsigned operations. Of 253.perlbmk regcomp.c(465:34) ∗s Unused course, even well-defined operations can be wrong; we 253.perlbmk regcomp.c(465:9) +s Unused 253.perlbmk regcomp.c(584:23) +s Unused discuss an example of particular interest, shown in Listing 2. 253.perlbmk regcomp.c(585:13) +s Unused The POSIX memcpy function is undefined if its source and 253.perlbmk sv.c(2746:19) −u Type promotion artifact 254.gap eval.c(366:34) ∗s Overflow check requiring -fwrapv target memory regions overlap. To guard against invoking 254.gap idents.c × 4 ∗u Hash memcpy incorrectly, the code checks that e (number of bytes 254.gap integer.c × 28 ∗s Overflow check requiring -fwrapv 254.gap integer.c × 4 +s Overflow check requiring -fwrapv copied) is less than the distance between w and d (both 254.gap integer.c × 4 −s Overflow check requiring -fwrapv 4 offsets into a memory region). If this check fails, a slower 255.vortex ut.c(1029:17) ∗u RNG memory copy that correctly handles overlap is invoked. 1 Only Add, Sub, Mul, and Div errors were checked in this experiment. (No Div overflows were found) However, when d ≥ w an unsigned overflow occurs, 2 Source, and line:column. For space, we summarize frequent ones as ‘× n’. resulting in an integer that is much greater than any potential 3 Operation Type(s), and Signed/Unsigned. 4 (Pseudo-)Random Number Generation. value for e, causing the safety check to pass even when the source and target regions overlap. This overflow was
6 Listing 3. Correct wraparound in a random number generator in 175.vpr Listing 5. Overflow in loop hoisting cost heuristic in 176.gcc 1 #define IA 1103515245u 1 if (moved_once[regno]) 2 #define IC 12345u 2 { 3 #define IM 2147483648u 3 insn_count *= 2 ; 4 4 ... 5 static unsigned int c_rand = 0; 5 if (already_moved[regno] 6 6 || (threshold * savings * m->lifetime) >= 7 /* Creates a random integer [0...imax] (inclusive) */ insn_count 8 int my_irand (int imax) { 7 || (m->forces && m->forces->done 9 int ival ; 8 && n_times_used[m->forces->regno] == 1)) 10 /* c_rand = (c_rand * IA + IC) % IM; */ 9 { 11 c_rand = c_rand * IA + IC ; // Use overflow to wrap 10 ... 12 ival = c_rand & (IM - 1); /* Modulus */ 13 ival = (int) ((float) ival * (float) (imax + 0.999) / (float) IM); Listing 6. Correct use of wraparound in bit manipulation in 176.gcc 1 #define POWER_OF_2_or_0(I) \ 14 return ival; 2 ((( I) & ( (unsigned)(I) - 1 )) == 0) 15 } 3 4 int Listing 4. Undefined overflow in 176.gcc to compute INT_MAX 5 integer_ok_for_set (value) 1 /* (unsigned) <= 0x7fffffff is equivalent to >= 0. */ 6 register unsigned value; 2 else if (const_op == ((HOST_WIDE_INT) 1 << ( 7 { mode_width - 1)) - 1) 8 /* All the "one" bits must be contiguous. 3 { 9 * If so, MASK + 1 will be a power of two or zero. 4 const_op = 0, op1 = const0_rtx; */ 5 code = GE; 10 register unsigned mask = ( value | ( value - 1 )); 6 } 11 return ( value && POWER_OF_2_or_0 ( mask + 1 ));}
reported by IOC and while investigating the report we arithmetic. This overflow is Type 1. discovered this potential bug. Fortunately, the version of gzip 4) 176.gcc: Listing 5 shows an undefined overflow that used in this experiment is rather old (based on 1.2.4) and may cause GCC to generate suboptimal code even in the 6 this issue has already been reported and fixed upstream case where the signed overflow is compiled to a wraparound as of version 1.4. Note that this bug existed in gzip as of behavior. The variable insn_count is used as a score in a 1993 and wasn’t fixed until 2010. Furthermore, the initial fix heuristic that decides whether to move a register outside of a 7 was overkill and was later fixed to be the proper minimal loop. When it overflows, this score inadvertently goes from condition to protect the memcpy. This illustrates the subtlety being very large to being small, potentially affecting code of overflow errors, and serves as a good example of well- generation. This overflow is Type 3. defined overflows leading to logic errors. In terms of the 5) 176.gcc: Listing 6 shows code that determines proper- taxonomy in Table II, this wraparound is Type 4. ties about the integer passed in at a bit level. In doing so, it 2) 175.vpr: This benchmark had four unsigned invokes various arithmetic operations (subtraction, addition, wraparounds caused by two similar implementations and another subtraction in the POWER_OF_2_or_0 macro) of random number generation. As shown in Listing 3, the that wrap around. These are all on unsigned integers and are developers documented their intentional use of unsigned carefully constructed to test the correct bits in the integers, so integer wraparound. These wraparounds are well-defined all of these wraparounds are benign. This example is a good and benign, and represent an important idiom for high- demonstration of safe bit-level manipulation of integers, a performance code. They are Type 2. popular cause of wraparound in programs. This overflow is 3) 176.gcc: This benchmark had overflows at 48 static Type 2. sites, some undefined and some well-defined. Listing 4 6) 176.gcc: In Listing 7 we see an allocation wrapper shows code that tries to compute the largest representable function that allocates a vector of n elements. It starts with signed integer. HOST_WIDE_INT is an int and mode_width 16 bytes and then adds (n − 1) ∗ 8 more to fill out the is 32, making the expression equivalent to (1 << 31) - 1. array, since the beginning rtvec_def struct has room for This expression is undefined in two different ways. First, 1 element by default. This works well enough (ignoring the in C99 it is illegal to shift a “1” bit into or past the type safety violations) for most values of n, but has curious sign bit. Second—assuming that the shift operation suc- cessfully computes INT_MIN—the subtraction underflows. In Listing 7. Wraparound in an allocation function in 176.gcc our experience, this idiom is common in C and C++ code. 1 /* Allocate a zeroed rtx vector of N elements */ Although compilers commonly give it the semantics that 2 rtvec rtvec_alloc (int n) { 3 rtvec rt; programmers expect, it should be considered to be a time 4 int i; bomb. A better way to compute INT_MAX is using unsigned 5 6 rt = (rtvec) obstack_alloc (rtl_obstack, 7 sizeof (struct rtvec_def) 6 http://git.savannah.gnu.org/gitweb/?p=gzip.git;a=commit;h= 8 + (( n - 1) * sizeof (rtunion))); b9e94c93df914bd1d9eec9f150b2e4e00702ae7b 9 ... 7http://git.savannah.gnu.org/gitweb/?p=gzip.git;a=commit;h= 10 return rt; 17822e2cab5e47d73f224a688be8013c34f990f7 11 }
7 Listing 8. Compute SIZE_MAX >> 1 in 197.parser Table IV 1 void initialize_memory (void) { EXPOSINGTIMEBOMBSIN SPEC CINT 2006 BY MAKING UNDEFINED 2 SIZET i, j; INTEGER OPERATIONS RETURN RANDOM RESULTS. " INDICATES THE 3 ... APPLICATIONCONTINUESTOWORK; $ INDICATES THAT IT BREAKS. 4 for (i=0, j =1; i < j; i = j, j = (2*j+1) ) 5 largest_block = i; 6 largest_block &= ALIGNMENT_MASK; Benchmark ANSI C / C++98 C99 / C++11 7 // must have room for a nuggie too 400.perlbench " " 8 largest_block += -sizeof(Nuggie); 401.bzip2 " $ 403.gcc $ $ behavior when n = 0. Of course, since we are using a 445.gobmk " " dynamic checker, it actually is called with n = 0 during 464.h264ref " $ a SPEC benchmarking run. 433.milc $ $ First, consider this code after the sizeof operators 482.sphix3 " $ " " are resolved and the promotion rules are applied: 435.gromacs " $ 16 + ((unsigned)(n-1)) * ((unsigned)8). When 436.cactusADM n = 0, we immediately see the code casting −1 to unsigned, which evaluates to UINT_MAX, or 232 − 1. The result is shown in Table III, our tool reported many sources of signed then multiplied by eight, which overflows with a result of wraparound as expected. The signed overflows are Type 1, 232 − 8. Finally, the addition is evaluated, which produces as they rely on undefined behavior and there is no mention the final result of 8 after wrapping around again. of -fwrapv in the documentation or source code. Using Although the overflow itself is benign, its consequences -fwrapv would make this Type 2, but non-portable because are unfortunate. Only eight bytes are allocated but the it would be limited to compilers that support -fwrapv. rtvec_def structure is 16 bytes. Any attempt to copy it by 10) Shift Overflows: In our examination of SPEC value will result in a memory safety error, perhaps corrupting CINT2000 we also checked for shift errors, finding a total the heap. This is one of the more intricate well-defined but of 93 locations. Of these, 43 were 1 << 31 which is an ultimately harmful overflows that we saw; it is Type 4. idiom for INT_MIN that’s legal in ANSI C, and another 38 7) 186.crafty: In this benchmark we found some Type 2 were shifts with a negative left operand which is also legal wraparounds in evaluate.c used to reason about a bitmap in ANSI C. For space reasons, and because this behavior is representation of the chessboard. Additionally, there is a fairly benign (and well-defined until C99), these are omitted Type 3 statistic miscalculation that seems like a minor from Table III and not discussed in detail. implementation oversight. Summary of Overflows in SPEC CINT2000: As shown 8) 197.parser: This benchmark had a number of over- in Table III, we found a total of 219 static sources of flows, including undefined signed overflows in a hash table overflow in eight of the 12 benchmarks. Of these, 148 were as indicated in Table III. Here we focus on an overflow in using unsigned integers, and 71 were using signed integers 197.parser’s custom memory allocator, shown in Listing 8. (32%).˜ Overall, the most common uses of overflow were This loop computes SIZE_MAX, setting largest_block to for hashing (128), overflow check requiring fwrapv (37), SIZE_MAX >> 1. Unsigned overflow is used to determine bit manipulation (25), and random number generation (6). when j exceeds the capacity of size_t (note that i = Finally, the vast majority of overflows found (both unsigned j when the loop terminates). While SIZE_MAX wasn’t in- and signed) were not bugs, suggesting occurrence of integer troduced until C99, it’s unclear why sizeof and a shift overflow by itself is not a good indicator of a security weren’t used instead. This overflow is Type 2: well-defined vulnerability or other functional error. and benign. D. Latent Undefined Overflows: Harmless, or Time Bombs? 9) 254.gap: Most of the undefined signed overflows in the SPEC 2000 suite are currently latent: today’s compilers The presence of integer overflows that result in undefined do not break them by exploiting the undefinedness. 254.gap behavior in a well-worn collection of software like SPEC is different: today’s compilers cause it to go into an infinite CINT raises the question: Do these overflows matter? After loop unless two’s complement integer semantics are forced. all—with the notable exception of 254.gap—the benchmarks From the LLVM developers’ mailing list:8 execute correctly under many different compilers. For each “This benchmark thinks overflow of signed mul- undefined overflow site in a benchmark program that exe- tiplication is well defined. Add the -fwrapv flag cutes correctly, there are two possibilities. First, the values to ensure that the compiler thinks so too.” coming out of the undefined operation might not matter. For example, a value might be used in a debugging printout, it We did not investigate the errors in this benchmark due to might be used for inconsequential internal bookkeeping, or the complex and obfuscated nature of the code. However, as it might simply never be used. The second possibility is 8http://lists.cs.uiuc.edu/pipermail/llvm-commits/ that these overflows are “time bombs”: undefined behaviors Week-of-Mon-20110131/115969.html whose results matter, but that happen—as an artifact of
8 today’s compiler technology—to be compiled in a friendly Listing 9. An overflow in IntegerLib 1 int addsi (int lhs, int rhs) { way by all known compilers. 2 errno = 0; To find the time bombs, we altered IOC’s overflow handler 3 if (((( lhs+rhs )^ lhs ) &(( lhs+rhs )^ rhs )) 4 >> (sizeof(int)*CHAR_BIT-1)) { to return a random value from any integer operation whose 5 error_handler("OVERFLOW ERROR", NULL, EOVERFLOW); behavior is undefined by the C or C++ standard. This creates 6 errno = EINVAL; 7 } a high probability that the application will break in an 8 return lhs+rhs; observable way if its execution actually depends on the 9 } results of an undefined operation. Perhaps amusingly, when operating in this mode, IOC is still a standards-conforming half of which were negations of INT_MIN. The SafeInt devel- C or C++ compiler—the standard places no requirements opers were aware that their code performed this operation, on what happens to a program following the execution of but did not feel that it would have negative consequences. an operation with undefined behavior. However, development versions of G++ do in fact exploit the SPEC CINT is an ideal testbed for this experiment be- undefinedness of -INT_MIN and we found that when SafeInt cause it has an unambiguous success criterion: for a given was built with this compiler, it returned incorrect results for test input, a benchmark’s output must match the expected some inputs. Basically, the G++ optimizer finally triggered output. The results appear in Table IV. In summary, the this time bomb that had been latent in SafeInt for some time. strict shift rules in C99 and C++11 are routinely violated We informed the developers of this issue and they promptly in SPEC 2006. A compiler that manages to exploit these released a new version of SafeInt that contains no undefined behaviors would be a conforming implementation of C or integer behaviors. C++, but nevertheless would create SPEC executables that We tested another safe integer library, IntegerLib [10], do not work. which was developed by CERT. This library contains 20 sites at which undefined integer overflows occur. One of E. Integer Overflows in the Wild them is shown in Listing 9; it is supposed to check if To understand the prevalence of integer overflow behav- arguments lhs and rhs can be added without overflowing. iors in modern open-source C and C++ applications, we ran However, at Line 3 the arguments are added without being IOC on a number of popular applications and libraries. In all checked, a bug that results in undefined behavior. A reason- cases, we simply compiled the system using IOC and then able solution for this case would be to cast the arguments ran its existing test suite (i.e., we typed “make check” or to an unsigned type before adding them. similar). For this part of our work, we focused on undefined 3) Other Codes: Six overflows in the GNU MPC library behaviors as opposed to well-defined wraparounds. Also, we that we reported were promptly fixed. We reported 30 explicitly avoided looking for bugs based on the stricter C99 overflows in PHP; subsequent testing showed that 20 have and C++11 shift rules; developer awareness of these rules been fixed. We reported 18 overflows in Firefox, 71 in GCC, is low and our judgment was that bug reports about them 29 in PostgreSQL, 5 in LLVM, and 28 in Python. In all would be unwelcome. of these cases developers responded in a positive fashion, 1) SQLite: SQLite is a compact DBMS that is extremely and in all cases except Firefox and LLVM we subsequently widely used: it is embedded in Firefox, Thunderbird, Skype, received confirmation that at least some of the overflows had iOS, Android and others. In March 2011 we reported 13 been fixed. Finally, we reported nine undefined overflows undefined integer overflows in the then-current version. in the GNU Multiple Precision Arithmetic Library, one in Although none of these undefined behaviors were believed BIND, and one in OpenSSL. We received no response from to be sources of bugs at the time, some of them could have the developers of these three packages. been time bombs. The main developer promptly fixed these Out of all the codes we tested, only three were completely overflows and IOC found no problems in the next version. free of undefined integer overflows: Kerberos, libpng, and IOC also found a lossy conversion from unsigned int to libjpeg. All three of these packages have had security vul- signed int that resulted in a negative value being used as an nerabilities in the past; undoubtedly the more recent versions array index. This code was triggered when SQLite attempted that we tested have been subjected to intense scrutiny. to process a corrupted database file. The SQLite developer 9 also promptly fixed this issue. V. PRIOR WORK 2) SafeInt and IntegerLib: SafeInt [7] is a C++ class for detecting integer overflows; it is used in Firefox and also Integer overflows have a long and interesting history. “used extensively throughout Microsoft, with substantial The popular Pac-Man game, released in 1980, suffered adoption within Office and Windows.” We tested SafeInt and from two known integer overflows that generate user-visible, found 43 sites at which undefined overflows occurred, about and surprising, artifacts [11], [12]. More recently, as buffer overflows in C and C++ programs have been slowly brought 9http://www.sqlite.org/src/info/f7c525f5fc under control, integer overflows have emerged as an im-
9 portant root cause of exploitable vulnerabilities in Internet- analysis tool for integer vulnerabilities. facing programs [3], [13]. The As-if Infinitely Ranged (AIR) integer model [20] is Solutions to integer overflow are almost as old as the an ambitious solution that is intended to be used online. It problem. For example, the IBM 702 provided a hardware- simply provides well-defined semantics for most of C/C++’s based implementation of variable-precision integers more integer-related undefined behaviors. AIR provides a strong than 50 years ago [14]. MacLisp, in the 1960s, provided the invariant—integer operations either produce representable first widely-available software implementation of arbitrary results or else trap—while being carefully designed to precision arithmetic. Even so, for a variety of reasons, to- minimally constrain the optimizer. An alternative online day’s low-level programming languages eschew well-known solution is provided by libraries such as SafeInt [7] and integer overflow solutions, forcing programmers to deal with IntegerLib [10], where checked operations must be explicitly modulo integers and undefined behaviors. invoked and overflows explicitly dealt with. SafeInt, how- Although there has been extensive work, especially during ever, is quite easy to use because it exploits C++’s exceptions the last decade or so, on tools and libraries for mitigating and operator overloading. integer-based security vulnerabilities, none of these tools VI.CONCLUSION have been used to understand the patterns of integer nu- merical overflows in real-world programs and benchmarks, We have conducted an empirical study of the prevalence which is the main focus of our work. Instead, those efforts and patterns of occurrence of integer overflows in C and have focused primarily on developing new tools and libraries C++ programs, both well-defined and undefined, and both and evaluating their efficacy. In particular, none of these intentional and inadvertent. We find that intentional uses projects has specifically attempted to examine the prevalence of wraparound behaviors are much more common than is of undefined behaviors, although there is data in some widely believed, e.g., over 200 distinct locations in SPEC of these papers about specific bugs. Moreover, none of CINT2000 alone. We identify a wide range of algorithms these projects has attempted to examine the prevalence of for which programmers use wraparound intentionally. intentional wraparound behaviors, or the idioms for which Unfortunately, we also observe that some of the inten- they are used, except the limited data in the paper on RICH. tional uses are written with signed instead of unsigned The RICH paper presents two relevant pieces of data [4]. integer types, triggering undefined behaviors in C and C++. First, it classifies integer numerical errors from MITRE’s Optimizing compilers are free to generate arbitrary results CVE database [15] as overflow, underflow, signedness, or for such code. In fact, we identified a number of lurking truncation errors. This classification does not show how “time bombs” that happen to work correctly with some prevalent numerical errors are across programs because the of today’s compilers but may fail with future compiler survey only looks at cases where overflows have already changes, such as more aggressive optimizations. Finally, we been reported, not a general collection of programs. Second, identified a number of previously unknown numerical bugs they briefly discuss some benign overflow behaviors that in widely used open source software packages (and even in are flagged as errors by their tool, and discuss for what safe integer libraries!), many of which have since been fixed algorithms those overflows are used. That study provides or acknowledged as bugs by the original developers. Even limited data about the prevalence and patterns of intentional among mature programs, only a small fraction are free of uses because their goal was different—to evaluate false integer numerical errors. positives from RICH. We study the empirical questions Overall, based on the locations and frequency of numer- systematically and in more detail. ical errors, we conclude that there is widespread misunder- Other prior research on mitigating integer-based security standing of the (highly complex) language rules for integer vulnerabilities is more tangential to our work. We briefly operations in C/C++, even among expert programmers. Our discuss that work to illustrate the solutions available. The results also imply that tools for detecting integer numerical tools vary from static analysis and dynamic instrumentation errors need to distinguish intentional from unintentional uses to libraries with various strategies to mitigate the problem. of wraparound operations—a challenging task—in order to RICH is a compiler-based tool that instruments programs minimize false alarms. to detect signed and unsigned overflows in addition to ACKNOWLEDGMENTS lossy truncations and sign-conversions [4]. BRICK [16] detects integer overflows in compiled executables using a We thank Tennessee Carmel-Veilleux, Danny Dig, Ganesh modified Valgrind [17]. The runtime performance is poor Gopalakrishnan, Alex Groce, Mary Hall, Derek Jones, (50X slowdown) and the lack of C-level type information Swarup Sahoo, and the ICSE 2012 reviewers for their in executable code causes both false positives and false insightful comments on drafts of this paper. This research negatives. SmartFuzz [18] is also based on Valgrind, but was supported, in part, by an award from DARPA’s Com- goes further by using whitebox testing to generate inputs puter Science Study Group, and by the Air Force Research leading to good test coverage. IntScope [19] is a static binary Laboratory (AFRL).
10 REFERENCES [11] D. Hodges, “Why do Pinky and Inky have different be- haviors when Pac-Man is facing up?” Dec. 2008, http: [1] MITRE Corporation, “CVE-2002-0639: Integer overflow //donhodges.com/pacman pinky explanation.htm ; accessed in sshd in OpenSSH,” 2002, http://cve.mitre.org/cgi- 21-Sept-2011. bin/cvename.cgi?name=CVE-2002-0639. [12] Wikipedia, “Pac-Man,” 2011, http://en.wikipedia.org/w/ [2] ——, “CVE-2010-2753: Integer overflow in Mozilla Firefox, index.php?title=Pac-Man&oldid=450692749#Split-screen ; Thunderbird and SeaMonkey,” 2010, http://cve.mitre.org/cgi- accessed 21-Sept-2011. bin/cvename.cgi?name=CVE-2010-2753. [13] S. Christey and R. A. Martin, “Vulnerability type distributions [3] S. Christey, R. A. Martin, M. Brown, A. Paller, and D. Kirby, in CVE,” MITRE Corporation, Tech. Report, May 2007, http: “2011 CWE/SANS Top 25 Most Dangerous Software Errors,” //cwe.mitre.org/documents/vuln-trends.html. MITRE Corporation, Tech. Report, September 2011, http:// cwe.mitre.org/top25. [14] Wikipedia, “Arbitrary-precision arithmetic,” 2011, http://en. wikipedia.org/wiki/Arbitrary-precision arithmetic ; accessed [4] D. Brumley, T. Chiueh, R. Johnson, H. Lin, and D. Song, 21-Sept-2011. “RICH: Automatically protecting against integer-based vul- nerabilities,” in Proc. of the Symp. on Network and Dis- [15] MITRE Corporation, “Common Vulnerability and Expo- tributed Systems Security (NDSS), San Diego, CA, USA, Feb. sures,” http://cve.mitre.org/. 2007. [16] P. Chen, Y. Wang, Z. Xin, B. Mao, and L. Xie, “Brick: A [5] “clang: a C language family frontend for LLVM,” http://clang. binary tool for run-time detecting and locating integer-based llvm.org/ ; accessed 21-Sept-2011. vulnerability,” in Proc. of the 4th Intl. Conf. on Availability, Reliability and Security, Fukuoka, Japan, Mar. 2009, pp. 208– [6] ISO, ISO/IEC 14882:2011: Programming languages — 215. C++. International Organization for Standardization, 2011. [Online]. Available: http://www.iso.org/iso/iso catalogue/ [17] N. Nethercote and J. Seward, “Valgrind: A program supervi- catalogue tc/catalogue detail.htm?csnumber=50372 sion framework,” in Proc. of the 3rd Workshop on Runtime Verification, Boulder, CO, Jul. 2003. [7] D. LeBlanc, “Integer handling with the C++ SafeInt class,” 2004, http://msdn.microsoft.com/library/default.asp? [18] D. Molnar, X. C. Li, and D. A. Wagner, “Dynamic test url=/library/en-us/dncode/html/secure01142004.asp. generation to find integer bugs in x86 binary Linux programs,” in Proc. of the 18th USENIX Security Symposium, 2009, pp. [8] ——, “Author’s blog: Integer handling with the C++ SafeInt 67–82. class,” http://safeint.codeplex.com/. [19] T. Wang, T. Wei, Z. Lin, and W. Zou, “IntScope: Automat- [9] C. Lattner and V. Adve, “LLVM: A compilation framework ically detecting integer overflow vulnerability in x86 binary for lifelong program analysis & transformation,” in Proc. of using symbolic execution,” in Proc. of the 16th Network and the 2004 Intl. Symp. on Code Generation and Optimization Distributed System Security Symp., San Diego, CA, USA, Feb. (CGO’04), Palo Alto, CA, USA, Mar. 2004. 2009.
[10] CERT, “IntegerLib, a secure integer library,” 2006, http: [20] R. B. Dannenberg, W. Dormann, D. Keaton, R. C. Seacord, //www.cert.org/secure-coding/IntegerLib.zip. D. Svoboda, A. Volkovitsky, T. Wilson, and T. Plum, “As- if infinitely ranged integer model,” in Proc. of the 21st Intl. Symp. on Software Reliability Engineering (ISSRE 2010), San Jose, CA, USA, Nov. 2010, pp. 91–100.
11