[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <365956254.15394397.1447786639162.JavaMail.zimbra@redhat.com>
Date: Tue, 17 Nov 2015 13:57:19 -0500 (EST)
From: Josh Bressers <bressers@...hat.com>
To: oss-security@...ts.openwall.com
Subject: Re: Re: Fwd: x86 ROP mitigation
----- Original Message -----
> 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
>
> (things like CPI/SafeStack could work too, but SafeStack requires
> hardware support that's not available on x86_64 and ARM yet)
>
> Preventing ROP by preventing hijacking of flow control in the first
> place isn't as good as outright preventing memory corruption (i.e. the
> bugs are still exploitable in many cases) but at least it wipes out a
> form of exploitation entirely and forces techniques that are not always
> going to accomplish everything that's desired. Chipping away at gadgets
> doesn't do that unless they're entirely gone, and it's hard to see how
> that could happen without higher performance costs than simply doing
> full memory safety (not like ASAN, but rather with GC).
>
>
Why not both?
Security is about layers, this is a nice place for a new security layer.
--
JB
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.
