[SC-L] GCC and pointer overflows [LWN.net]

[Robert C. Seacord]

Ken,

Comment below.
> FYI, here's an interesting article (and follow-on discussions) about a 
> recent bug in the GCC compiler collection.
>
> http://lwn.net/Articles/278137/
>
> The bug, which has been documented in a CERT advisory, affects C code 
> in which, under some circumstances, buffer bounds checking can be 
> optimized out to produce binaries that are susceptible to buffer 
> overflows.  The article includes a couple examples that really help 
> illustrate the issue -- very interesting reading, IMHO.
>
> Of course, many/most SC-Lers will no doubt jump on this as another 
> example of why C is such a dangerous language to write (secure) code 
> in, and that's fine.  But, I see the issue at least a little 
> differently: a compiler making decisions for the programmer and 
> producing executable code that does not accurately conform to what the 
> programmer coded.  We've all heard of security-related optimizing 
> issues for years, right?  Well, here's a prime example of one in action.
To be fair to gcc, the code in question is "undefined behavior" which 
means that the C standard gives the compiler lease to deal with the code 
in any manner they wish.  This means that they do not need to diagnose 
the problem, generate object code, or generate correct code.  This is a 
problem with the C language--the onus is on the developer to write 
"conforming" applications.

The reason we dinged gcc in this case was because versions of the 
compiler prior to v 4.2 did generate object code in this case that was 
consistent with the user model (e.g., that adding a pointer to a integer 
could result in wrapping).  Version 4.2 silently changed this behavior 
without providing a flag or option to diagnose the issue.  They have 
since modified their compiler to warn on this issue, and once this 
version of the compiler is released we will update the vul note to 
recommend this version of the compiler be used.

We are looking at this as a prototype for similar vulnerability notes 
dealing with erroneous or unexpected behavior in tools that can lead to 
the introduction of vulnerabilities in software, so I would be 
interested in feedback as to if vulnerability notes of this sort are of 
value.

rCs