From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Eager To: Florian Weimer Cc: "Joseph S. Myers" , gcc@gcc.gnu.org Subject: Re: Buffer Overflow Attacks Date: Thu, 18 Oct 2001 15:02:00 -0000 Message-id: <3BCF5170.12820483@mvista.com> References: <87y9meypy7.fsf@deneb.enyo.de> X-SW-Source: 2001-10/msg01037.html Florian Weimer wrote: > > "Joseph S. Myers" writes: > > > On Sun, 14 Oct 2001, Florian Weimer wrote: > > > >> According to the language standard, buffer overflow detection for > >> character pointer types is possible only for buffers which are not > >> nested in other objects (in struct or union objects). Overflowing > >> character buffers has a well-defined effect if the buffer is contained > >> in an object (and other objects follow the buffer inside this object), > >> so a C implementation is not free to detect such errors (which is only > >> possible if the buffer overflow triggers undefined behavior). ;-) > > > > This is a gross over-simplification of the problem of exactly when an > > object can be accessed through a given pointer. For details see Nick > > Maclaren's "What is an object when it is at home?" paper, except that I > > don't think he's published it beyond the UK and WG14 reflectors. For > > examples where the committee has ruled that bounds of sub-objects can't be > > exceeded, see DR#017 question 16, and DRs #051 and #178 relating to the > > "struct hack". > > The struct hack for character arrays results in strictly conforming > programs because arithmetic on pointers to a character type is not > restricted in any way, as long the enclosing object is not left. This > is a consequence of 6.3.2.3(7). I think that this is stretching reading of this paragraph. Creating a valid pointer address does not mean that deferencing the pointer is defined. If you have the following: struct foo { char c[31]; int i; } f; char *p1; You can create a pointer which points beyond the end of the array f.c: p1 = &f.c[32]; The effect of dereferencing this pointer is undefined. There are few restrictions on the layout of structures. Commonly there would be padding bytes placed between c and i. Referencing these padding bytes is undefined. Indeed, in a hypothetical processor with very fine grained memory protection, any padding bytes placed between c and i in the struct may be both unreadable and/or unwritable. (We won't consider the havoc this might cause to memcopy.) -- Michael Eager eager@mvista.com 408-328-8426 MontaVista Software, Inc. 1237 E. Arques Ave., Sunnyvale, CA 94085