On Mon, Mar 04, 2002 at 10:18:05AM +0100, Mariusz Woloszyn wrote:
> I was investigating that issue and found no vulnerabilities in current
> (3.0) version of this compiler. It protects a lot better than StackGuard
> (reordering the variables and copying arguments), but seems to provide
> more overhead.
> Please let me know if there are any security problems with it I didn't
> find. I have to treat is as best buffer overflow protecting compiler (it
> gives protection for all attacs I described in Phrack article!), from
> security point of view.

Hi --

I've misplaced my notes and code verifying the below, which I am doing
from (possibly fallible) memory.

Mid-September 2001, when I looked into Propolice for gcc 3.0.1, I
found a number of flaws in its "StackGuard Aspect":

(1) The temporary variable for the correct-canary-value was being
spilled to the stack in the assembly output of the *first* example I
constructed of a buffer overflow. A simple overflow scribbling the
desired return-address over and over would change the
correct-canary-value to the same thing it changed the saved return
address to.

(2) It has a complex and somewhat unexplained formula for deciding
which functions to canary and which not. The check let through
functions that I could buffer overflow.

(3) The canary initializations and checks floated uncomfortably far
from the prologue and epilogue in the assembly code. Possibly past an
opportunity to overflow the stack.

(4) I'm not sure, but I think tail and sibling calls didn't receive
canary checks. If this is true, functions could be exited without
checking the canary protecting the return address that the goto'd
function would use. It would merely lay down its own to protect the
already corrupted return address.

-- Perry
_______________________________________________
Immunix-users mailing list
Immunix-usersmail.wirex.com
http://mail.wirex.com/mailman/listinfo/immunix-users

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]