Re: Format Bugs in Windows Code?

[Thomas Dullien <Dullien () GMX NET>]

> I don't, offhand, but this made me think of a possible way to test for
> the
> possibility of format bugs in binary applications without source,
> provided
> they're linked dynamically with the MFC runtime.  Interpose wsprintf et
> al.
> with ones that do a IsBadWritePointer on the format string.  If the
> format
> string is writable, it's likely a variable, and possibly susceptible to
> user
> input.

This is _not_ a good idea. Assuming a program has been internationalized
it will load format strings et al using LoadString() and then use these
strings afterwards. Using your approach, you would get a _huge_ number
of false positives. Secondly, as format string problems most frequently
appear in logging function you would sometimes have to generate pretty
exotic error conditions which are hard to trigger unless you read either
the source or the disassembly. If you do that, you can save yourself the
extra step of hooking functions and just use your debugger :)

Concerning format string problems: When testing Netscape Enterprise Web-
server for these problems, I found that the logging dunctions pass user-
submitted data into a sprintf() function as format string. But the user-
submitted data is properly filtered, meaning that every '%' is replaced by
'%%' and so on. When I removed this filtering in the debugger, it was
properly exploitable under Win32.
(For those that didn't read the above I HAVE NOT FOUND A VULERABILITY IN
NETSCAPE ENTERPRISE !)

BTW, has anyone ever noticed that theoretically FormatMessage() can be
used for a format string problem as well ? :)

Cheers,
Thomas Dullien
Mandatory Military Service Sucks

--
Sent through GMX FreeMail - http://www.gmx.net