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 _______________________________________________ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. _______________________________________________
