Re: Blue Boars question...

[dullien () GMX DE (Thomas Dullien)]

At 03:35 PM 7/10/2000 -0300, you wrote:

>         I'm not so sure about this...
>         If you are using C calling convention (as almost everybody here is)
> the caller is responsible for restoring the stack after the call, not the
> callee.
>         In fact, this line of code will compile/link/and work just fine:
>         printf("%p%p%p%p%p%p%p%p%p%p%p");

Sorry, my fault. You're right that it will not crash due to popping extra
data off the stack as the caller handles that. The two ways to 'reliably'
crash an application is using either %n or %s until you hit a non-mapped
or read/write protected memory area.

>         I would like to bring something into attention here:
>         the n version of this functions will write not the " numbers of bytes
> written so far..." as you (and man pages) say, but the number of bytes that
> whould have been writen so far IF THERE WAS SPACE FOR IT... meaning:
>         snprintf(buf,1,"%.10000d%d",&anInt)
>         will write 10000 in anInt, even when buf's size is said to be 1

I can't confirm this. During testing and playing around with the WuFTP
SITE EXEC stuff on FreeBSD 4.x a colleague of mine found out that
on FreeBSD we cannot have a total buffer size larger than 0x400 (1024)
bytes and that trying to work it the way you described above doesn't
always work. I haven't investigated these details and don't know whether
there are other implementation-specific changes.

>         I would vote for not calling this kind of bugs 'buffer overflows' or
> so, cause there is no need to overflow the buffers to exploit this, I'll use
> "input validation error", as CERT and many more do, until somebody finds a
> better name for it...

What about "user-supplied format string error" :) ? I think that would describe
it rather accurately....

Greets,
Thomas Dullien