OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Subject: Re: Blue Boars question...
From: Thomas Dullien (dullienGMX.DE)
Date: Mon Jul 10 2000 - 22:36:39 CDT

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