On 06/17/2016 08:29 AM, Michael Matz wrote:
Hi,
On Fri, 17 Jun 2016, Bernd Schmidt wrote:
On 06/17/2016 04:03 PM, Michael Matz wrote:
But does this really improve something? Essentially you're replacing
<random bytes1> 0xc9 0xc3 <random bytes2>
(the end of a function containing "leave;ret") with
<random bytes1> 0xe9 <four random bytes> <random bytes2>
where the four random bytes are different for each rewritten function
return (but correlated as they differ exactly by their position
difference).
I'm not sure why the latter sequence is better?
I think I'm missing what you're trying to say. The latter sequence does not
contain a return opcode hence it ought to be better?
The "0xe9 <four random bytes>" essentially is the leave+return opcode,
after all it jumps to them (let's ignore the possibility that the jump
target address might contain a 0xc3 byte). So if the attacker finds some
interesting gadget in <random bytes1> I don't see how the change from
leave+ret to jump-to-leave+ret changes anything from a threat avoidance
perspective. It's fully possible that I don't understand the threat
vector of ROP correctly, in which case I'd also like to know :)
A couple things to note.
I expect that we'll be doing work in the assembler and linker to address
cases where 0xc3 shows up in immediate displacements, absolute addresses
and the like. The easiest ones are when 0xc3 shows up as a byte
displacement for pc-relative jumps, but there are others.
I haven't looked at the random bytes stuff Bernd has done, but its
likely to ensure that the bad guys can't jump into the middle of an
instruction prior to the leave and use that to skip the leave.
Jeff
