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

[Brett Glass <brett () LARIAT ORG>]

At 11:36 PM 7/22/2000, Greg A. Woods wrote:

> 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.

True. This suggests that a better way of creating printf-like functions
would be to use a format string plus a bounds-checked array. This would
prevent stack inspection and smashing.

One could even go one step farther and insist upon a pair of parallel arrays
and bounds checking. This would solve the problem of catching the case where
there were MORE items to print than there were format specifiers. This
usually indicates an uncaught logical error.

[Snip.... I agree with the points I'm not reproducing here]

> 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.

That's right. What we really have in the current implementation is
a "micro-language" that is interpreted at runtime. Worse still, it has
"in-band signaling," no bounds checking, no consistency checking, and
no type checking.

> 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.

Unless the language is crippled, people will always be able to do
things which are dumb and/or insecure. But it's nice if the usual
ways of doing things are more robust, and if constructs which are
far apart semantically are far apart syntactically. (C commits
many sins in this area, such as "=" vs. "==").

> As a note to all students out there... [Sugestion for thesis topic]

Yes, I like this idea. The paper would be suitable for presentation
at conferences such as USENIX, too (as was Theo de Raadt's paper
on the strl* functions).

At 04:20 AM 7/24/2000, Hannah Schröter wrote:

> However, setproctitle("foo") is correct and safe!

Many exploitable functions are safe with constant arguments.

At 11:41 AM 7/23/2000, mixter () 2XS CO IL wrote:

> It is a bad idea to have any format functions accept format strings
> that aren't hard coded at compile time.

There are legitimate reasons for being able to format at runtime.
However, it should be difficult to make gross errors.

Another mechanism that would make format strings less likely to be
exploited is "tainting." Trivial in Perl, and implementable via
via a library in C or via a set of taint-checked classes in an
object-oriented language.

--Brett