Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 18 Nov 2015 13:16:07 +0100
From: Florian Weimer <>
To:, Bernd Schmidt <>
Cc: Jeff Law <>
Subject: Re: Re: Fwd: x86 ROP mitigation

On 11/18/2015 02:57 AM, Solar Designer wrote:

> I'd like more detail on the plan of dealing with function epilogues, if
> there is a plan for that.
> 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.

It's about things like this:

   1c6d3:       48 8b 4c 24 58          mov    0x58(%rsp),%rcx
   1c6d8:       64 48 33 0c 25 28 00    xor    %fs:0x28,%rcx
   1c6df:       00 00
   1c6e1:       75 31                   jne    1c714
   1c6e3:       48 83 c4 68             add    $0x68,%rsp
   1c6e7:       5b                      pop    %rbx
   1c6e8:       5d                      pop    %rbp
   1c6e9:       41 5c                   pop    %r12
   1c6eb:       41 5d                   pop    %r13
   1c6ed:       41 5e                   pop    %r14
   1c6ef:       41 5f                   pop    %r15
   1c6f1:       c3                      retq
   1c714:       e8 47 b7 ff ff          callq  <__stack_chk_fail@plt>
   1c719:       0f 1f 80 00 00 00 00    nopl   0x0(%rax)

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.


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.