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 10:34:46 -0700
From: Jeff Law <law@...hat.com>
To: Solar Designer <solar@...nwall.com>
Cc: Bernd Schmidt <bschmidt@...hat.com>, oss-security@...ts.openwall.com,
        Florian Weimer <fweimer@...hat.com>
Subject: Re: Fwd: x86 ROP mitigation

On 11/17/2015 09:24 AM, Bernd Schmidt wrote:
> On 11/17/2015 04:39 PM, Solar Designer wrote:
>  > A few days ago, Bernd Schmidt posted this gcc patch:
>  >
>  > https://gcc.gnu.org/ml/gcc-patches/2015-11/msg01773.html
>  >
>  > "This adds a new -mmitigate-rop option to the i386 port. The idea is to
>  > mitigate against certain forms of attack called "return oriented
>  > programming" that some of our security folks are concerned about.
>  > [...]
>  > This patch is a small step towards preventing this kind of attack.
>  > I have a few more steps queued (not quite ready for stage 1), but
>  > additional work will be necessary to give reasonable protection."
>  >
>  > This was followed with a few tweets:
> [...]
> Obviously, I'm aware that this by itself isn't going to do very much. I
> said so in my submission email! But you have to start somewhere, and
> these pieces were ready.
Right.  It's a small piece of a much longer term effort to start 
spoiling ROP gadgets, both those which are inherent in the normal 
instruction stream (ie function epilogues) and those which are a result 
of the variable length instruction nature of the x86 ISA.


>
>  > Bernd, I'd appreciate it if you describe your plan in a reply to this
>  > e-mail.  Please keep oss-security CC'ed.
>
> I wouldn't call it my plan. I'm essentially in the role of implementing
> requirements that others with more knowledge of the security issues come
> up with.
>
> The plan, as far as it goes, is to start picking low-hanging fruit, and
> hopefully build up over time until we have something that actually
> provides protection. Things that we've discussed include:
Right.  I don't think anyone believes this stuff will make a significant 
difference *at this stage*.  Thus, we aren't planning announcements or 
any promotion of the work.

The obvious idea is to keep knocking off sources of ROP gadgets, 
hopefully reaching a point where ROP gadgets are reasonably hard to find 
& exploit in GCC generated code at some point in the future.

As each bundle of work reaches completion, it will be submitted to the 
appropriate project (GCC & binutils).  There's no value in holding back 
any particular mitigation technique.  They'll just keep dropping as 
they're completed.  FWIW, mod R/M is the only work that I see landing in 
GCC 6 given its development window closed earlier this week.

If you have any questions, feel free to contact me directly.

Jeff



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