Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ