Re: Buffer Overflow Attacks

[Michael Eager <eager at mvista dot com>]

Florian Weimer wrote:
> 
> "Joseph S. Myers" <jsm28@cam.ac.uk> 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