Re: machine independent protection from stack-smashing attack

[Gerardo Richarte <core.lists.bugtraq () CORE-SDI COM>]

John Viega wrote:
> Sure, you're lining up arrays next to each other, but that doesn't
> solve every case.  Consider the following example, slightly modified
> from the StackGuard page:
>
> foo(char * arg) {
>     char *  p[1];    // a vulnerable pointer
>     char a[25];    // the buffer that makes the pointer vulnerable
>     p[0] = arg;
>     gets(a);    // using gets() makes you vulnerable
>     gets(p[0]);    // this is the good part
> }

        here I come once again... sorry to be repetitive...

        To exploit this problem described here (if not fixed rearranging variables with ProPolice), and the original in
StackGuard page:

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
}

        An attacker doesn't need to write on the return address in
stack, and probably not even execute he's own code (but some libc
function steed).
        I know that ProPolice and StackGuard claim only that they
protect against stack smashing attacks, and changes in the return
address.
        In this kind of exploits you have the ability to write whatever
you want wherever you want in memory (specially using gets() that doesn't break input in \x00 but \n), and when that is 
the case there
are a lot of beautiful different places where to write something
useful.
        My point here is: you are discussing something that will not
change anything, even if you get to some better solution than the XOR
random canary method, am I wrong?

        richie

--
A390 1BBA 2C58 D679 5A71 - 86F9 404F 4B53 3944 C2D0
Research and Developement - CoreLabs - Core SDI
http://www.core-sdi.com

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