|| ||Florian Weimer <fw-AT-deneb.enyo.de>|
|| ||"Robert C. Seacord" <rcs-AT-cert.org>|
|| ||Re: US-CERT Vulnerability Note VU#162289|
|| ||Sun, 13 Apr 2008 23:51:00 +0200|
|| ||Gerald.Williams-AT-infineon.com, gcc-AT-gcc.gnu.org, crd-AT-cert.org|
* Robert C. Seacord:
> i agree that the optimization is allowed by C99. i think this is a
> quality of implementation issue, and that it would be preferable for
> gcc to emphasize security over performance, as might be expected.
I don't think this is reasonable. If you use GCC and its C frontend,
you want performance, not security. After all, the real issue is not
the missing comparison instruction, but the fact that this might lead to
subsequent unwanted code execution. There are C implementations that
run more or less unmodified C code in an environment which can detect
such misuse, but they come at a performance cost few are willing to pay.
Without such a sacrifice, the only thing you can come up is "We are
secure, sometimes, but we can't tell you precisely when", which doesn't
seem to be that helpful.
The problem I see with this particular case is that the type of
comparison you describe is bogus even if translated to straight machine
code because it assumes an awful amount of detail about the target
environment. Give us a real-world example of an affected program that
runs on a significant number of GCC-supported platforms, and at least I
would be more inclined to take view this as an issue in GCC. Just to be
clear, I wouldn't be suprised if some real-world code breaks, but this
code hasn't been written in a portable style in the first place and
should be considered buggy anyway.
C programmers usually don't care much about the corner cases of the
language. It's pretty easy to come up with things which are generally
assumed to work, but are not actually guaranteed by the standard. There
are several ways to deal with this, like better reading material for
programmers, or some C variant that writes down the perceived implicit
programmer expectations. But tweaking the compiler to match these
expectations, without a semi-formal description of what they are, isn't
worth the effort, IMHO.
> i think we mean what we say, which is "*Avoid newer versions of gcc"
> and *"avoiding the use of gcc versions 4.2 and later." i don't see
> any verbiage that says "use a different compiler".
"Better use older GCC versions" is still disparaging to GCC developers,
like "you can only rely on CERT/CC advisories issued in 2007 and earlier
years". And it's been mentioned in various places that this is
incorrect, some 4.1 versions show similar behavior.
to post comments)