Bugtraq mailing list archives
Re: StackGuard with ... Re: [Paper] Format bugs.
From: aland () STRIKER OTTAWA ON CA (Alan DeKok)
Date: Sat, 22 Jul 2000 11:43:26 -0400
Theo de Raadt <deraadt () cvs openbsd org> wrote:
Automated tools do not help because you still have to check for the last category by hand, so you might as well read everything.
That's like saying "'Make' doesn't help, because you can always fall back to 'ls -l' and 'cc ...'" Automated tools HELP. They are not ENOUGH. I tried to make this clear in the documentation for my scanner. An automated scanner can help to protect you against the obvious security bloopers.
[ ... ] hand-made log()-style functions which end up calling v*() functions
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. I'm not a compiler expert, nor am I familiar with GCC. But I would guess that one solution to these variable argument functions would be to fix va_start() and friends. That is, va_arg() should ensure that it doesn't walk off of the current stack frame. In the header files I have for for GCC 2.7.2.3, va_arg() is defined as: #define va_arg(AP, TYPE) (AP = (__gnuc_va_list) ((char *) (AP) + __va_rounded_size (TYPE)), \ *((TYPE *) (void *) ((char *) (AP) - __va_rounded_size (TYPE)))) 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. 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. 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. Alan DeKok.
Current thread:
- Re: StackGuard with ... Re: [Paper] Format bugs., (continued)
- Re: StackGuard with ... Re: [Paper] Format bugs. Linus Akesson (Jul 24)
- Re: StackGuard with ... Re: [Paper] Format bugs. Dan Harkless (Jul 25)
- 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)