Re: GCC extension for protecting applications from format string attacks

[Crispin Cowan <crispin at wirex dot com>]

Makoto Iwamura wrote:

> Iwamura and Etoh would make a GCC extension for protecting applications
> from format string attacks. The idea is as follows. Any suggestion and
> comments will be appreciated.

The Immunix team, in collaboration with Mike Frantzen and Jamie Lokier, has
developed a tool called FormatGuard that protects against printf format
string vulnerabilities (format bugs).  Rather than a GCC patch, FormatGuard
defines printf (and friends) as a macro, and uses tricks with CPP to count
the arguments to the macro before forwarding it to a wrapped printf function
that checks the format string before passing it on to printf.

   * Because FormatGuard is a macro definition and a library function, we
     have packaged it as an enhancement to glibc 2.2, rather than a hack to
     GCC
   * Brief description here  http://immunix.org/formatguard.html
   * Full paper to appear at USENIX Security 2001
     http://www.usenix.org/events/sec01/
   * Immunix OS 7.0 is completely built with FormatGuard  http://immunix.org/

FormatGuard was narrowly announced to the Immunix users' mailing list.  We
are planning a broad announcement (i.e. to Bugtraq) in the next month or so.


> When the extension finds the function call with variable number of
> arguments, it generates a series of bytes data as its mark and the number
> of arguments to the machine code of the calling function. The generated
> data is independent from the execution of the original calling function.
> Therefore, the compiled code is portable to the same UNIX system.
>
> The mark is used for deciding whether the calling function is compiled by
> our GCC extension or not. You can handle the number of arguments in your
> library if the calling function is compiled by the extension. Unless that,
> you can ignore the value. So, you can also write a portable library. Our
> idea enables keeping up both calling and called function's portability.

There was discussion about this kind of thing last September on Vuln-dev,
starting (more or less) here
http://archives.neohapsis.com/archives/vuln-dev/2000-q3/thread.html#743  At
issue is that the current varargs protocol just dumps the arguments onto the
stack.  It is trivial to define a new varargs-like protocol that provides
either an argument count or an argument termination symbol, but it is much
harder to do so while making separately compiled varargs calls compatible
with existing standard varargs libraries.  If Iwamura & Etoh's proposal can
solve this problem, I don't understand it from what was said here.


> Actually machine codes of the function calling printf() become the
> following code.
> Surely,<number of arguments> etc. don't affect the original action.
>
>    .
>    .
>    .
> call printf
> jmp .L14
> .byte <mark>
> .long <number of arguments>
> .L14:
>    .
>    .
>    .
>
> When you get the number of arguments in the function printf, you can write
> the following programs at the entrance of the printf function.

So you're dropping an argument count onto the stack as an argument?  How do
you keep standard printf from interpreting it as an actual argument?


> The GCC
> built-in function __builtin_return_address() is used for getting the "jmp
> .L14" address next to the call instruction. The get_number_of_args
> function gives an example how to find <mark> and get <number of
> arguments>.
> Note that printf() cannot find <mark>, it means calling function doesn't
> have a number of arguments.

This attempts to solve the problem of a protected printf library being called
by a standard program, but not the other way around.  However, since varargs
defines arguments as being of completely arbitrary type, I don't understand
how the protected printf avoids accidentally interpreting an actual argument
as an argument count.

Crispin

--
Crispin Cowan, Ph.D.
Chief Research Scientist, WireX Communications, Inc. http://wirex.com
Security Hardened Linux Distribution:                http://immunix.org