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

[mixter () 2XS CO IL]

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.

On Fri, 21 Jul 2000, Brett Glass wrote:

> Which brings up a more interesting question:
>
> Don't these errors really reflect more fundamental problems in the
> development tools? It seems to me that the bugs arose because:
>
> 1) Format strings in the C libraries use a sort of "in-band signalling" --
> that is, they can mix text with format designators. This means that
> passing the text you want to print as the format string produces results
> that appear to be correct.
>
> 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.
>
> The latter problem can be solved by insisting upon the use of macros
> that mandate a minimum number of arguments and produce a warning
> or error message otherwise.
>
> The former requires changing the conventions used by the standard C
> libraries, which is probably infeasible.
>
> --Brett Glass
>
> At 03:52 PM 7/21/2000, Theo de Raadt wrote:
>
> > >   There is no substitute, however, for a careful line-by-line audit of
> > > code.
> >
> > In my mind, there never was.
> >
> > When this came up, we (Todd Miller, Todd Fries, and I) did an audit on
> > our source tree for the following cases
> >
> >        *printf()
> >        err*()
> >        warn*()
> >        syslog()
> >        setproctitle()
> >        hand-made log()-style functions which end up calling v*() functions