Bugtraq mailing list archives
Re: StackGuard with ... Re: [Paper] Format bugs.
From: "Greg A. Woods" <woods () WEIRD COM>
Date: Sun, 23 Jul 2000 01:36:27 -0400
[ On Friday, July 21, 2000 at 22:48:57 (-0600), Brett Glass wrote: ]
Subject: Re: StackGuard with ... Re: [Paper] Format bugs. 2) The C language itself has no way of specifying a MINIMUM number of arguments for a function call. Had the compiler noted that setproctitle() and similar functions need at least two arguments, the mistakes would have been caught from the get-go.
Just to be slightly pedantic... Yes the ISO-C language can specify the minimum number of arguments for a function call. However for the class of printf-like calls there's no way to specify that there must be one more than the obvious minimum number of parameters iff the format string contains one or more format specifiers. I.e. there's no way to specify an argument of an arbitrary type in a prototype without causing at least some kind of warning in most modern compilers; and there's no obvious way at the language level to interpret the meaning of what might be passed in an array of characters that might have been constructed at runtime (or indeed might even be raw user input). For example, the prototype for printf() is: int printf(const char *, ...); I.e. any call to printf() must include at minimum one argument which is a pointer to a character which may not be changed by the function (or rather usually interpreted as a pointer to the beginning of an array of characters which may not be changed by the function). However what it really should be is something like this, assuming of course that the format string always contains at least one format specifier: int printf(const char *, *(void *), ...); If the above construct were a legal C prototype that always required at least one additional parameter in all printf() calls then at least some of the current string of bugs might have been caught. However such a prototype would force lots of currently legal code to be converted to use something like: printf("%s", "string with no format specifiers"); Unfortunately this would lead to programmers doing: printf("str", ""); and then ultimately the same buggy: printf(user_input, ""); It should also be noted that while some modern C compilers can detect mismatches between printf-style function call parameters and the format strings given in a string that's specified at compile time, there's no way in C, short of implementing compiler-assisted run-time checks, to ensure that the format string passed to an arbitrary printf-style function is always safely matched by all of the other parameters passed to that function. Even worse is the problem that in C it's trivial to implement a new kind of printf-style function that uses completely different format specifiers and even escape characters than the "standard" printf() ones. I.e. it is flatly impossible to solve this problem completely in a language that has abilities like C. (this whole mess is why I still vehemently dislike prototypes and wish ANSI had left C well enough alone and just kept using lint to check these kinds of things!) As a note to all students out there: the above is a suggestion for a potential paper or even thesis topic (i.e. design an extension to C that would allow a function to discover at run-time what number and type of parameters it was called with and write a run-time checking version of printf() that uses this feature; and then compile and test a few gigabytes of freeware programs with it and report on how it all fares both as a security enhancement as well as from a performance perspective; and finally maybe even show how this mechanism compares in a more general sense with the <stdarg.h> hacks). A second topic might be to prove whether or not any existing computer language can prevent programmers from easily writing printf-like functions that are inherently insecure or whether such language extensions are always necessary for paranoid programming. -- 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: CheckPoint FW1 BUG, (continued)
- Re: CheckPoint FW1 BUG Nicolas FISCHBACH (Jul 18)
- [Paper] Format bugs. Pascal Bouchareine (Jul 18)
- (New ?) Macro security hole in Word 97 Bongard, Dominique (Jul 21)
- Re: (New ?) Macro security hole in Word 97 Bronek Kozicki (Jul 22)
- Jakarta-tomcat.../admin Scott Morris (Jul 21)
- StackGuard with ... Re: [Paper] Format bugs. Alan DeKok (Jul 21)
- [RHSA-2000:044-02] Updated PAM packages are available. bugzilla () REDHAT COM (Jul 21)
- Re: StackGuard with ... Re: [Paper] Format bugs. Theo de Raadt (Jul 21)
- Roxen security alert: Problems with URLs containing null characters. Peter Bortas (Jul 21)
- Re: StackGuard with ... Re: [Paper] Format bugs. Brett Glass (Jul 21)
- Re: StackGuard with ... Re: [Paper] Format bugs. Greg A. Woods (Jul 24)
- Re: StackGuard with ... Re: [Paper] Format bugs. Brett Glass (Jul 25)
- Re: StackGuard with ... Re: [Paper] Format bugs. mixter (Jul 24)
- 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)