This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: US-CERT Vulnerability Note VU#162289
- From: Florian Weimer <fw at deneb dot enyo dot de>
- To: "Robert C. Seacord" <rcs at cert dot org>
- Cc: mark at codesourcery dot com, gcc at gcc dot gnu dot org, Chad Dougherty <crd at cert dot org>
- Date: Tue, 08 Apr 2008 22:02:18 +0200
- Subject: Re: US-CERT Vulnerability Note VU#162289
- References: <47FA59B5.5000606@cert.org>
* Robert C. Seacord:
> I agree with you that the behavior that gcc exhibits in this case is
> permitted by the ISO/IEC 9899:1999 C specification
> <http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1124.pdf>
> (§6.5.6p8). I believe the vulnerability is that gcc may *silently*
> discard the overflow checks and that this is a recent change in
> behavior.
The problem is that there is no overflow check in the code. At a purely
syntactic level, it appears that there is an overflow check. But this
is true for integer overflows, too.
There are some issues that are debatable, like non-two's-complement
arithmetic for signed integers (also a feature of GCC and other
compilers)--or operator new[] overflows, for which I'd really like to
see run-time checks.
But treating C pointers as machine addresses is pretty clearly flawed
code. For instance, are pointers compared as signed or unsigned
integers at the instruction level? Which behavior do you need so that
your checks actually work as expected?