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

[Dan Harkless <dan-bugtraq () DILVISH SPEED NET>]

mixter () 2XS CO IL writes:
> The problem is that the functions using format strings should be
> secure by default, but they awfully fail to be. That IS an issue at
> the conceptual level, because the standards themselves allow something
> that can very easily open security holes.
>
> It is a bad idea to have any format functions accept format strings that
> aren't hard coded at compile time. All these functions need to have one
> format argument at one location, which definitely needs to be a hard-coded
> string, (using and enforcing const). Per definition, it is arguably
> possible to supply variable format strings in a program, but it is rarely
> practically used, and it shouldn't be practically used. At least, when
> supplying any format function a non-constant format argument, the compiler
> should spit out a big warning, and it should do that by default without
> warnings enabled.

Others have already mentioned the internationalization coding style that
would make that a bad idea.

On the other hand, I do think that useful compiler warnings could be added
for these types of things.  It'd be nice to have a warning that'd complain
about calling "known printf-like" varargs functions (including
setproctitle() et al.) with a single non-constant parameter.

You would _not_ want it on by default, because of (innocent) code like:

    if (flag = 1)
        color = "red";
    else
        color = "green";

    printf(color);  /* ideally should be fputs(color, stdout), but... */

Such a warning should be part of gcc -Wall's repertoire, though.  Can
someone suggest this to the gcc developers?  (Unfortunately I don't have
time at the moment to look up the preferred method of submitting such a
suggestion.)

----------------------------------------------------------------------
Dan Harkless                   | To prevent SPAM contamination, please
dan-bugtraq () dilvish speed net  | do not mention this private email
SpeedGate Communications, Inc. | address in Usenet posts.  Thank you.