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.