Bugtraq mailing list archives
Re: StackGuard with ... Re: [Paper] Format bugs.
From: "Greg A. Woods" <woods () WEIRD COM>
Date: Sun, 23 Jul 2000 01:48:00 -0400
[ 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>
Current thread:
- Re: StackGuard with ... Re: [Paper] Format bugs., (continued)
- Re: StackGuard with ... Re: [Paper] Format bugs. Valentin Nechayev (Jul 24)
- Re: StackGuard with ... Re: [Paper] Format bugs. Greg A. Woods (Jul 24)
- Re: StackGuard with ... Re: [Paper] Format bugs. Dick St.Peters (Jul 25)
- Re: StackGuard with ... Re: [Paper] Format bugs. Hannah Schröter (Jul 24)
- Re: StackGuard with ... Re: [Paper] Format bugs. Stephen J. Friedl (Jul 24)
- Re: StackGuard with ... Re: [Paper] Format bugs. Casper Dik (Jul 24)
- Re: StackGuard with ... Re: [Paper] Format bugs. stanislav shalunov (Jul 24)
- Re: StackGuard with ... Re: [Paper] Format bugs. Daniel Jacobowitz (Jul 24)
- Re: StackGuard with ... Re: [Paper] Format bugs. Alan DeKok (Jul 22)
- Re: StackGuard with ... Re: [Paper] Format bugs. Keith Owens (Jul 24)
- Re: StackGuard with ... Re: [Paper] Format bugs. Greg A. Woods (Jul 24)
- Re: StackGuard with ... Re: [Paper] Format bugs. Gerardo Richarte (Jul 24)
- Re: StackGuard with ... Re: [Paper] Format bugs. Greg A. Woods (Jul 25)
- Re: StackGuard with ... Re: [Paper] Format bugs. Theo de Raadt (Jul 24)
- Chasing bugs / vulnerabilties Michael S Hines (Jul 24)
- Re: Chasing bugs / vulnerabilties Kurt Seifried (Jul 25)
- Re: StackGuard with ... Re: [Paper] Format bugs. Pascal Bouchareine (Jul 21)
- Re: StackGuard with ... Re: [Paper] Format Ronald Huizer [Crew] (Jul 24)
- More bad censorware John Pettitt (Jul 21)
- Re: StackGuard with ... Re: [Paper] Format bugs. Gerardo Richarte (Jul 24)