Re: StackGuard with ... Re: [Paper] Format bugs.

["Greg A. Woods" <woods () WEIRD COM>]

[ On Saturday, July 22, 2000 at 11:43:26 (-0400), Alan DeKok wrote: ]
> Subject: Re: StackGuard with ... Re: [Paper] Format bugs.
>
>   The problem (in the end) is NOT printf and friends, it's <stdarg.h>,
> and the va_*() functions.  They can trivially be convinced to walk up
> the stack, returning arguments which were not passed to the function.
> This is a bug in the C compiler.

No, it's not a bug, and especially not a bug in the compiler.  It's a
design flaw, or rather a design *feature* in the language!

>   This would appear to be the root of the problem.  va_arg() doesn't
> do bounds checking.  That's a hell of a security hole, as we've seen
> recently.  The user-space/programmer fixes to code are nothing more
> than band-aids to work around a security hole in the compiler.

It's not possible to do bounds checking without: a) changing the function
calling interface so that the number of parameters, as well as the type
of each parameter, can be passed to the function; as well as b)
inventing a new language construct that could be used to implement
something like an enhanced <stdarg.h> interface.

>   va_arg() should be a built-in function, which ensures that it
> doesn't return more arguments than were passed.  It should be possible
> to add these checks to the gcc, as the compiler knows the size of the
> current stack frame.

Be careful here, very careful!  The compiler does not know the size of
the current stack frame in C.  It is variable length (thus the hint
given in the name of va_arg() itself! ;-) and must be tested at run
time.

>   There's no substitute for fixing the *root* of the problem, to
> ensure that mistakes which are easy to make do not have adverse side
> effects.

This is a rather hard problem to fix without breaking C at the root.

It is very important to realise that C is not pascal (i.e. C is not a
strongly typed language with run-time bounds checking) and there are
*lots* of us who do NOT want to be coddled by our language or even our
compiler -- we just want something slightly more maintainable and
portable than raw (or macro) assembly languages!  Whether this means it
is wrong to write security-sensitive software in languages like C, or
not, is a very separate question.

--
                                                        Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods () acm org>      <robohack!woods>
Planix, Inc. <woods () planix com>; Secrets of the Weird <woods () weird com>