Re: ImmuniX OS Security Alert: StackGuard 1.21 Released

[core.lists.bugtraq () CORE-SDI COM (Iván Arce)]

Crispin Cowan wrote:

> Gerardo Richarte wrote:
>
> >     I think that having this kind of overflow available, StackWard is
> > still vulnerable to a little smarter attack.
>
>
> >     You may think that this code example is too tricky, but there was a
> > buffer overflow in bind's inverse query
> > (http://www.securityfocus.com/vdb/bottom.html?vid=134) like this. This
> > makes me remember of some code I wrote to exploit this for Sparcs, as
> > it was just one call deep, it was imposible to overwrite the return
> > address, so, by using a memcpy() to a pointer I could overwrite (like
> > that one in
> > the example code) I overwrited part of the libc in memory, lets say
> > printf, so when the program called printf() after the second memcpy(),
> > instead of calling the original printf() it called my code: Here you
> > have an exploit that can be used still if you have StackWard.
>
> You appear to be describing a buffer overflow that attacks a pointer, and

no hes describing an attack that exploits a buffer overflow, the particular case

is that the vulnerability allows the attacker to overwrite a pointer, the ways
to exploit that are many, Gerardo mentions overwritting a libc function, other
things
that come to mind:
. Modifying the PLT
. Modifying the GOT
. Modifiying the _dynamic struct
. Overwritting global variables (i somehow recall an exploit that modifies a
global
  FILE struct  under some *BSD flavor)
. Overwritting C++ object destructors

> not the activation record.  StackGuard only claims to protect the
> activation record, so while this is a legitimate vulnerability that
> StackGuard does not prevent, it is not actually a bug in StackGuard.

Well, your original post said:

> Consider this vulnerable code:
>
> foo(char * arg) {
>     char *    p = arg;    // a vulnerable pointer
>     char a[25];    // the buffer that makes the pointer vulnerable
>
>     gets(a);    // using gets() makes you vulnerable
>     gets(p);    // this is the good part
> }
>
> In attacking this code, the attacker first overflows the buffer a[] with
> a goal of changing the value of the char * p pointer.  Specifically,
> 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.

"in attacking this code" is a key phrase here...
I believe Gerardo tries to say that it is posible to attack that code in many
different ways and therefore:

> 3. Solution:  The XOR Random Canary

It is not so.

It's just a way to prevent ONE kind of exploitation of that code

> The result of this method is that we have the same protection as with
> the classic Random canary, and also the property that the attacker cannot

Exactly, "the same protection"
It just doesnt fix the problem of exploiting the code
in a way that does not involve:

> modify the return address without invalidating the canary word.

This in no way implies that StackGuard is not an effective solution against
common buffer overflow vulnerabilities and the usual way of exploiting them,
but i think its  importart to point out exactly against what it DOES protect you

and against what it DOESNT.

that said, i now run to trademark StackWard....
btw, what about StackWars?
-ivan

--
"Understanding. A cerebral secretion that enables one having it to know
 a house from a horse by the roof on the house,
 It's nature and laws have been exhaustively expounded by Locke,
 who rode a house, and Kant, who lived in a horse." - Ambrose Bierce

==================[ CORE Seguridad de la Informacion S.A. ]=============
Iván Arce
Presidente
PGP Fingerprint: C7A8 ED85 8D7B 9ADC 6836  B25D 207B E78E 2AD1 F65A
email: iarce () core-sdi com
http://www.core-sdi.com
Pte. Juan D. Peron 315 Piso 4 UF 17
1038 Capital Federal
Buenos Aires, Argentina.              Tel/Fax : +(54-11) 4331-5402
Casilla de Correos 877 (1000) Correo Central
================================================================

--- For a personal reply use iarce () core-sdi com