oss-sec mailing list archives

Re: Re: Fwd: x86 ROP mitigation


From: Daniel Micay <danielmicay () gmail com>
Date: Tue, 17 Nov 2015 22:13:29 -0500

On 17/11/15 05:11 PM, Rich Felker wrote:
On Tue, Nov 17, 2015 at 01:52:07PM -0500, Daniel Micay wrote:
Is that really the right approach vs. preventing hijacking of flow
control via return pointers and function pointers? It doesn't really
seem like there's an end game in mind where it actually prevents ROP
rather than just removing many useful gadgets. Making useful ROP gadgets
harder to find doesn't mean much, since tools are used to find them and
the tools can be improved if it becomes necessary.

i.e. why not just go with something like PaX's RAP

My understanding is that it's not ABI-compatible with non-RAP code, so
you'd essentially be going with a whole new ABI. If so, this is going
to be completely impractical for most users. Am I mistaken?

AFAIK, it's ABI compatible with code compiled with it. Hard to say since
the implementation is not yet public. You do need to use it everywhere
to truly take advantage of it though. It might still protect the
function pointers reachable by the attacker without full coverage but...
that's not at all ideal.

Mitigations like this aren't comparable to ones providing incomplete
detection of memory corruption like _FORTIFY_SOURCE where even a small
amount of coverage can end up preventing vulnerabilities from being
exploited. A ROP migitation is only removing an exploitation technique /
making exploitation unreliable (hopefully enough that it can't be brute
forced) / requiring additional bugs to work around it so... it's no good
if there are easy ways around it for an attacker. It actually has to
enforce something meaningful.

RAP is essentially breaking the exploitation technique across the board.
It's not insurmountable but it's not incomplete either. And it can be
improved from the meaningful starting point. It's really hard to see how
removing all usable ROP gadgets can succeed. Maybe it can, but it's hard
to believe without seeing a compelling roadmap.

Attachment: signature.asc
Description: OpenPGP digital signature


Current thread: