search menu icon-carat-right cmu-wordmark

CERT Coordination Center

C compilers may silently discard some wraparound checks

Vulnerability Note VU#162289

Original Release Date: 2008-04-04 | Last Revised: 2008-10-08

Overview

Some C compilers optimize away pointer arithmetic overflow tests that depend on undefined behavior without providing a diagnostic (a warning). Applications containing these tests may be vulnerable to buffer overflows if compiled with these compilers.

Description

In the C language, given the following types:

        char *buf;
        int len;

some C compilers will assume that buf+len >= buf. As a result, code that performs wrapping checks similar to the following:

len = 1<<30;
[...]
if(buf+len < buf)  /* wrap check */
  [...overflow occurred...]


are optimized out by these compilers; no object code to perform the check will appear in the resulting executable program. In the case where the wrap test expression is optimized out, a subsequent manipulation of len could cause an overflow. As a result, applications that perform such checks may be vulnerable to buffer overflows.

Wrapping checks that use methods similar to the one described above depend on undefined behavior. Conforming implementations are permitted to perform the optimization by the ISO/IEC 9899:1999 C specification (§6.5.6p8) as undefined behavior. Even if a conforming implementation currently generates object code for an undefined behavior, future versions of the compiler are not obligated to do the same; this behavior may be viewed as an opportunity for further optimization. To ensure that such changes to the compiler do not invalidate assumptions, developers should follow the recommendations described in CERT C Secure Coding recommendation MSC15-C and rule ARR38-C to avoid this error. Furthermore, compilers are not required to issue diagnostics for undefined behavior, so there is frequently no easy way to identify undefined behavior in code, particularly during manual code audits.

Note that this issue does not strictly constitute a vulnerability in the compilers themselves. Rather, this behavior may introduce vulnerabilities in applications that include similar code and are compiled with affected compiler implementations. Existing code that relies on the undefined behavior in the wrapping check is particularly susceptible to this behavior.

Multiple implementations are known to perform this optimization. This optimization may be affected by the setting of the optimization level as well as other flags. Additional information about affected implementations can be found in the Systems Affected section of this document.

Impact

An application that performs wrapping checks based on an expression such as the one described above may be vulnerable to buffer overflow if compiled with affected compiler implementations. The nature of the resulting vulnerability would be specific to the application and depends on how the affected code is used.

Solution

Use casts
Cast objects of type char* to uintptr_t before comparison. The faulty wrapping check listed above would be written

#include <stdint.h>
[...]
if((uintptr_t)buf+len < (uintptr_t)buf)
   [...]

Alternatively, developers can use size_t on platforms that do not provide the uintptr_t type. Developers should also follow the recommendations described in CERT C Secure Coding rule ARR38-C.

Avoid affected compiler implementations
Application developers and vendors of large codebases that cannot be audited for use of the defective wrapping checks are urged to avoid using compiler implementations that perform the offending optimization. Vendors and developers should carefully evaluate the conditions under which their compiler may perform the offending optimization. In some cases, downgrading the version of the compiler in use or sticking with versions of the compiler that do not perform the offending optimization may mitigate resulting vulnerabilities in applications.

Vendor Information

162289
 

GNU Compiler Collection Affected

Updated:  July 29, 2008

Status

Affected

Vendor Statement

The behaviour of pointer overflow has now changed as of the following
(as yet unreleased) versions:

gcc 4.2.4
gcc 4.3.1
gcc 4.4.0

and all subsequent versions (4.2.x where x >= 4, 4.3.y where y >= 1,
4.z where z >= 4).

The optimization under discussion is for comparisons between P + V1
and P + V2, where P is the same pointer and V1 and V2 are variables of
some integer type.  The C/C++ language standards permit this to be
reduced to a comparison between V1 and V2.  However, if V1 or V2 are
such that the sum with P overflows, then the comparison of V1 and V2
will not yield the same result as actually computing P + V1 and P + V2
and comparing the sums.

The new behaviour as of the above releases is that this optimization
is performed by default at -O2 and above, including -Os.  It is not
performed by default at -O1 or (of course) -O0.  The optimization may
be enabled for -O1 with the -fstrict-overflow option.  The
optimization may be disabled for -O2 and above with the
-fno-strict-overflow option.

When the optimization is enabled, cases where it occurs may be
detected by using -Wstrict-overflow=N where N >= 3.  Note that using
this warning option is likely to yield a number of false positive
reports--cases where this or other overflow optimizations are being
applied, but where there is no actual problem.

Please see the gcc manual for more information about these options.

Vendor Information

We are not aware of further vendor information regarding this vulnerability.

Addendum

Vendors and developers using the GNU C compiler should consider using versions of GCC that do not perform the optimization such as those listed above or GCC 4.1.2 or earlier versions (but NOT 4.1.0).

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Intel Corporation Not Affected

Notified:  April 17, 2008 Updated: April 25, 2008

Status

Not Affected

Vendor Statement

I tried the given program with our compiler on IA32 linux (Where int and
ptr are both 32 bits).  I couldn't ever get it to optimize the test away.  It may be
possible under some circumstances to get this to happen, but the test case sent
doesn't show that for me.  I tried icc -O1, -O2, and -O3 levels of optimization,
and none of them showed the problem.

Vendor Information

We are not aware of further vendor information regarding this vulnerability.

Sun Microsystems, Inc. Not Affected

Notified:  April 17, 2008 Updated: August 26, 2008

Status

Not Affected

Vendor Statement

We have run the provided test case on various versions of Sun's C
compilers with various levels of optimization and we do not believe
that they are impacted by this issue.

Vendor Information

We are not aware of further vendor information regarding this vulnerability.

Cray Inc. Unknown

Notified:  April 23, 2008 Updated: April 23, 2008

Status

Unknown

Vendor Statement

We have not received a statement from the vendor.

Vendor Information

We are not aware of further vendor information regarding this vulnerability.

Hewlett-Packard Company Unknown

Notified:  April 17, 2008 Updated: April 17, 2008

Status

Unknown

Vendor Statement

We have not received a statement from the vendor.

Vendor Information

We are not aware of further vendor information regarding this vulnerability.

IBM Corporation Unknown

Notified:  April 17, 2008 Updated: April 17, 2008

Status

Unknown

Vendor Statement

We have not received a statement from the vendor.

Vendor Information

We are not aware of further vendor information regarding this vulnerability.

Microsoft Corporation Unknown

Notified:  April 17, 2008 Updated: April 17, 2008

Status

Unknown

Vendor Statement

We have not received a statement from the vendor.

Vendor Information

We are not aware of further vendor information regarding this vulnerability.

Silicon Graphics, Inc. Unknown

Notified:  April 17, 2008 Updated: April 17, 2008

Status

Unknown

Vendor Statement

We have not received a statement from the vendor.

Vendor Information

We are not aware of further vendor information regarding this vulnerability.

Sybase Unknown

Notified:  April 17, 2008 Updated: April 17, 2008

Status

Unknown

Vendor Statement

We have not received a statement from the vendor.

Vendor Information

We are not aware of further vendor information regarding this vulnerability.

Wind River Systems, Inc. Unknown

Notified:  April 17, 2008 Updated: April 17, 2008

Status

Unknown

Vendor Statement

We have not received a statement from the vendor.

Vendor Information

We are not aware of further vendor information regarding this vulnerability.


CVSS Metrics

Group Score Vector
Base
Temporal
Environmental

References

Acknowledgements

Felix von Leitner originally published information about this behavior in the gcc compiler. Russ Cox later noticed this behavior as well and provided additional information and assistance.

This document was written by Chad R Dougherty and Robert C Seacord.

Other Information

CVE IDs: None
Date Public: 2006-04-17
Date First Published: 2008-04-04
Date Last Updated: 2008-10-08 14:13 UTC
Document Revision: 68

Sponsored by CISA.