[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20151119092834.GA11121@openwall.com>
Date: Thu, 19 Nov 2015 12:28:34 +0300
From: Solar Designer <solar@...nwall.com>
To: oss-security@...ts.openwall.com
Subject: Re: Fwd: x86 ROP mitigation
Thank you all for the responses. The project makes more sense to me now.
Florian wrote:
> > It seems to me that if the stack canary check happened directly before
> > the RET instruction, after restoring the registers, it would make it
> > more difficult to abuse the RET instruction. With the code above, you
> > can just jump to the address 1c6e7 and have access to quite a few useful
> > POP instructions.
On Wed, Nov 18, 2015 at 05:33:37PM +0100, Fabio Pagani wrote:
> You are right. Attackers will have access to POP instruction and
> potentially to any instruction found in an unaligned fashion.
> Shifting down the check will work but it's very dangerous, because you
> are accessing a part of the stack that was deallocated with the add.
Perhaps the POP instructions can be replaced with MOVs (since the stack
pointer would not yet be right for the POPs) and the ADD postponed until
after the check? That way, the check would still be inside the would-be
desirable gadget, and would hopefully spoil it (since the gadget would
be invoked without a prior invocation of the function's prologue).
> Actually I've implemented G-Free for X86-64 (except the "symbolic
> addresses" part) in the LLVM backend.
> The source will be released max in 2 weeks, but anyway i will be very
> happy to discuss and help for a GCC implementation.
Cool!
Alexander
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
