Re: Format Bugs in Windows Code?

[Pavel Kankovsky <peak () ARGO TROJA MFF CUNI CZ>]

On Sun, 10 Sep 2000, Crispin Cowan wrote:

> Is that actually true?  It seems to me that if the compiler implements
> varargs at all, then it is exploitable.

You can, at least theoretically, implement variadic functions in a way
providing a good degree of safety: any call of this form

        f(fixed_1, ..., fixed_N, variadic_1, ..., variadic_M)

would be compiled as

        f(fixed_1, ..., fixed_N,
          TYPEOF(variadic_1), variadic_1, ...,
          TYPEOF(variadic_M), variadic_M, TERMINATOR)

where TYPEOF(expr) provides some machine readable description of expr's
type (Objective C has something similar), and TERMINATOR is an artifical
"type descriptor" not corresponding to any actual type. All values of
TYPEOF() and the value of TERMINATOR are of the same type; perhaps
pointers pointing to something with a magic number to make the detection
of errors easier.

va_arg macro would check whether the desired type is compatible with the
provided one, and abort when they are not (or when TERMINATOR is hit).

Of course there are some disadvantages: some performance penalty, and the
lack of binary compatibility. Of course, it will also break any code
not using the standard macros to access the variadic arguments (such a
code is broken anyway).

> Fair enough.  It does seem more difficult to detect a format bug in
> binary code than to detect overflowable buffers.  The "fuzz" approach
> of barfing long strings at every available orifice detects
> overflowable buffers, but you have to do something more deft to detect
> format bugs.

Is there any reason why using strings "polluted" with format tags should
not work? Repeated %s's or %n's are probably the best choice because it
is very likely a vulnerable program will go down in flames when it tries
to interpret such a string.

--Pavel Kankovsky aka Peak  [ Boycott Microsoft--http://www.vcnet.com/bms ]
"Resistance is futile. Open your source code and prepare for assimilation."