Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <564CC17A.3060905@redhat.com>
Date: Wed, 18 Nov 2015 11:20:42 -0700
From: Jeff Law <law@...hat.com>
To: Solar Designer <solar@...nwall.com>, Bernd Schmidt <bschmidt@...hat.com>
Cc: oss-security@...ts.openwall.com, Florian Weimer <fweimer@...hat.com>
Subject: Re: Fwd: x86 ROP mitigation

On 11/17/2015 06:57 PM, Solar Designer wrote:
>
> I'd like more detail on the plan of dealing with function epilogues, if
> there is a plan for that.
There's not a lot of detail at this point.  For function's that don't 
escape, the compiler has visibility of both the call and return sites. 
So for those we can look at indirection, address mangling and the like. 
  It's something Bernd is just starting to experiment with.

Once something escapes, then we may be looking at something like 
stack-protector-all or somehow emitting a sequence that's painful to try 
and exploit while being semantically equivalent.  The concern is that 
with the cost of stack-protector-all there'll be resistance to using 
that as the mitigation technique.


>
> I'm not sure if this fits under:
>
>>    * Look into an idea Florian had for improving stack-protector
>>      epilogues.
>
> or if that's (more likely) something entirely different.
No, it's based on some experiments that show changing the stack 
protector epilogue can result in an epilogue sequence that is painful to 
exploit.


jeff

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.