Re: StackGuard with ... Re: [Paper] Format bugs.

[pb () GROLIER FR (Pascal Bouchareine)]

Hi,

You achieved a nice analysis on this topic.
This leads me to facts i'd like to underline,
some old thoughs are broken with this "new" topic.

You may have clearly stated these below, but my brain is quite
damaged by a few hours of sleep and a charged business week.

Please forgive any repetitions/mistakes, and as usual my bad english.. :)

On Fri, Jul 21, 2000 at 12:21:20PM -0400, Alan DeKok wrote:
> [ Crispin Cowan (author of StackGuard) responds: ]
>
>    At the time StackGuard was built, and at present, blind overflows
>    are the primary means of attack.  This % printf hack has the potential
>    to change that. [1]
>
>
>
>   As the "Format bugs" paper pointed out, it is possible to READ the
> stack, as well as to write (nearly) arbitrary data to the stack of the
> target machine.  [..]

Of course when processed data is dumped to the user. This breaks things
in two parts : a very dangerous problem, as you stated, and - erh, a very
dangerous problem too, where attacker blindly writes to memory.

Difference with a classical buffer overflow is the way user can write
memory, of course. Format bugs allow targetted writes, where one doesn't
need to overwrite a contiguous area to address distinct memory locations.

I played a little around stack data writings last night. Your only
limitation is buffer space. printf() and a malloc'ed area for fgets()
is for example a very dangerous context. (see badly coded attachement)

This allows you to write *exactly* (including '\0') what you want
at any address in (+w) memory.

I mean any address: overwriting your own input buffer to change
the next %n converter argument seems possible, doesn't it ?

>   There is no obvious method of using constant canaries to protect the
> stack against an introspective attacker.  They do, however, protect
> very well against blind buffer overflows.
>
>   Stack Guard has another method to protect against attacks which
> do not overflow the stack, but in which:
>
>     ... the attacker can cause the p pointer to point anywhere in
>     memory, but especially at a return address record in an
>     activation record.  When the program then takes input and stores
>     it where p points, the input data is stored where the attacker
>     said to store it. [2]

(i have not taken time to fully examine stackguard,
 so i may be wrong below)

%n attacks (not using buffer overflow, but rewriting a given address
in memory) use a simplest derived scheme. Here, 'p' is a quadruplet
of addresses in the input buffer, followed by some %n.

Thus, format attack involving buffer overflows are still a derivated
way to have code executed remotely.

[ snipped canarie guess ]

>   We should note that this sort of attack is NOT the classic and
> well-known buffer overflow attack.  As Crispin says above, this attack
> appears to be new.

Right, and you quite demonstrate that protecting the stack against
format attacks with canaries isn't a solution.

>   In summary, an attacker who is introspective of the stack can bypass
> all predictable methods of protecting the stack with canaries.

An attacker with full read access on my process page owns me, i bet.
What a pity for key-based authentications (servers.. and clients too :
think about a wu-ftpd + radius daemon that would give-away radius secrets)

This breaks most security-through-obscurity based architecture.

> Programmers should carefully audit their code for the sort of % printf
> style vulnerabilities.  An automated scanner PScan which *may* help
> (but which isn't perfect) is available.[3]
>
>   There is no substitute, however, for a careful line-by-line audit of
> code.

Of course, programming errors should be avoided where possible :)

> [1] Crispin Cowan <crispin () wirex com>, private corresponce
> [2] http://immunix.org/StackGuard/emsi_vuln.html
> [3] http://www.striker.ottawa.on.ca/~aland/pscan/
> [4] http://immunix.org/stackguard.html

--
Kalou.

((void(*)())(char[]){0x31, 0xdb, 0x31, 0xc0, 0xb0, 0x01, 0xcd, 0x80})();


<HR NOSHADE>
<UL>
<LI>text/plain attachment: wu.c
</UL>