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
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ