Executive Summary
Summary | |
---|---|
Title | C compilers may silently discard some wraparound checks |
Informations | |||
---|---|---|---|
Name | VU#162289 | First vendor Publication | 2008-04-04 |
Vendor | VU-CERT | Last vendor Modification | 2008-05-02 |
Severity (Vendor) | N/A | Revision | M |
Security-Database Scoring CVSS v3
Cvss vector : N/A | |||
---|---|---|---|
Overall CVSS Score | NA | ||
Base Score | NA | Environmental Score | NA |
impact SubScore | NA | Temporal Score | NA |
Exploitabality Sub Score | NA | ||
Calculate full CVSS 3.0 Vectors scores |
Security-Database Scoring CVSS v2
Cvss vector : (AV:N/AC:M/Au:N/C:P/I:P/A:P) | |||
---|---|---|---|
Cvss Base Score | 6.8 | Attack Range | Network |
Cvss Impact Score | 6.4 | Attack Complexity | Medium |
Cvss Expoit Score | 8.6 | Authentication | None Required |
Calculate full CVSS 2.0 Vectors scores |
Detail
Vulnerability Note VU#162289C compilers may silently discard some wraparound checksOverviewSome 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.I. DescriptionIn the C language, given the following types: char *buf;
[...] 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 lencould 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-A 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. II. ImpactAn 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.III. SolutionUse castsCast objects of type char* to uintptr_t before comparison. The faulty wrapping check listed above would be written
[...] if((uintptr_t)buf+len < (uintptr_t)buf) [...] 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. Systems Affected
Referenceshttps://www.securecoding.cert.org/confluence/x/SgHm 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.
|
Original Source
Url : http://www.kb.cert.org/vuls/id/162289 |
CAPEC : Common Attack Pattern Enumeration & Classification
Id | Name |
---|---|
CAPEC-8 | Buffer Overflow in an API Call |
CAPEC-9 | Buffer Overflow in Local Command-Line Utilities |
CAPEC-10 | Buffer Overflow via Environment Variables |
CAPEC-24 | Filter Failure through Buffer Overflow |
CAPEC-46 | Overflow Variables and Tags |
CWE : Common Weakness Enumeration
% | Id | Name |
---|---|---|
50 % | CWE-189 | Numeric Errors (CWE/SANS Top 25) |
50 % | CWE-119 | Failure to Constrain Operations within the Bounds of a Memory Buffer |
CPE : Common Platform Enumeration
Type | Description | Count |
---|---|---|
Application | 6 |
Open Source Vulnerability Database (OSVDB)
Id | Description |
---|---|
44142 | Gnu GCC Length Testing Code Failure Code Compilation Weakness |