On Mon Apr 02 05:16AM 2001, Crispin Cowan <crispinWIREX.COM> wrote:
> fish stiqz wrote:
>
> > On Sat Mar 31 10:47PM 2001, Makoto Iwamura <iwamuraPB.HIGHWAY.NE.JP> wrote:
> > > If you implement printf()(fprintf(),syslog(),,,etc.) that doesn't access
> > > arguments more than "num" value, you can protect applications from format
> > > string attacks. If we will make a new built-in function instead of calling
> > > get_number_of_args, you can get the number of arguments with only one
> > > statement added.
> >
> > No, You cannot assume that in order to exploit a format string
> > vulnerability an attacker must use more arguments than are specified
> > at compile time. You *can* successfully exploit a format string
> > vulnerability with the same number of arguments or less.
> > Consider the following example: (look similar to splitvt?? ;)
>
> That's a very interesting development. We've been looking for such an example
> for some time, but considered it only a theoretical possibility.
>
> The particular straw man and exploit that fis stiqz presents depends on doing a
> classical stack smash. Immunix systems are built with both FormatGuard and
> StackGuard, so this won't actually work. Can stiqz's example be altered or
> generalized so that it does not depend on a buffer overflow? I.e. so that one
> can achieve the usual format bug effect of overwriting *arbitrary* program
> state, rather than linear adjacent state as in this example?
>
> Thanks,
> Crispin

Crispin, As you are probably aware, the only reason this fails on your
particular machine is that the canary value inserted by the StackGuard
compiler gets wiped. I don't know of any ways to get around this while
still using only one argument in my particular example. However, this
does not exempt this "formatted overflow" method (or the "stretching"
method as scut calls it) from being a valid form of exploitation. Nothing
is keeping the overflown buffer from being on the heap, allowing other
critical parts of the program to be overwritten (as detailed in the many
heap overflow papers).

Now, from my research so far, I dont think the "formatted overflow" has
the potential to overwrite an arbitrary state, but instead acts exactly
like a buffer overflow, overwriting only the linear space adjacent to
the buffer itself.

This particular method is interesting because of the fact that you can't
stop it by disabling the %n specifier, and that you can't stop it by
regulating the amount of arguments passed to the function. The only
way to prevent this type of attack is to ensure that there are no
user-modifiable format strings in your program. The downside to it
is that it only works on a function that writes to a buffer in an
unchecked manner, such as sprintf(). It doesn't make much sense to try
to apply these concepts to printf(), which only prints to the screen.

In summary, while StackGuard and FormatGuard are good ideas, they do
not protect against all attacks using either of these methods (or a
combination of the two (the "formatted overflow")).

Thanks for your comments.

- fish stiqz

--
fish stiqz <fishanalog.org>
   irc>irl?werd():lame()

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]