This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Buffer Overflow Attacks
- To: mike stump <mrs at windriver dot com>
- Subject: Re: Buffer Overflow Attacks
- From: Florian Weimer <fw at deneb dot enyo dot de>
- Date: Wed, 31 Oct 2001 19:23:54 +0100
- Cc: eager at mvista dot com, gcc at gcc dot gnu dot org, jsm28 at cam dot ac dot uk
- References: <200110182359.QAA00865@kankakee.wrs.com>
mike stump <mrs@windriver.com> writes:
> Well, I can't comment on the exact code you gave, but I can comment on
> C++ and code like this:
>
> struct foo {
> char c[31];
> int i;
int j;
(Otherwise the argument below is wrong, especially if sizeof(int)
equals sizeof(char).)
> } f;
>
> *(((char*)&f)+32) and *(((char*)&f)+33) are allowed.
Yes, that's right even for C. But this doesn't help in the case I
originally presented. While we certainly have (&(f.c[30])) equal to
(((char *)&f) + 30) (they both refer to the same object), it occured
to me that &(f.c[32]) is indeed undefined, but (((char *)&f) + 32) is
defined. It's a bit funny that if two objects which compare equal
show such different behavior, but I think that's way it's specified in
the standard.
So I have to retract my original claim that it was impossible to do
buffer overflow checks in such cases. After all, a pointer in C-speak
(or "address", as in "address-of operator") is not very similar to a
machine address.