[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <564B54BA.6090203@redhat.com>
Date: Tue, 17 Nov 2015 17:24:26 +0100
From: Bernd Schmidt <bschmidt@...hat.com>
To: Solar Designer <solar@...nwall.com>
Cc: oss-security@...ts.openwall.com, Jeff Law <law@...hat.com>,
Florian Weimer <fweimer@...hat.com>
Subject: Re: Fwd: x86 ROP mitigation
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.
> 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:
* modr/m bytes (posted)
* sib bytes (relatively simple extension, some parts done)
* immediates (patch exists but has some remaining problems)
* also look into avoiding not just ret bytes but also indirect jumps
and such. More interesting because that may span instructions.
* See if we can get as to detect cases where two adjacent instructions
contain a pattern useful for attacks (like the indirect jump) and
put a nop in between.
* Look into an idea Florian had for improving stack-protector
epilogues.
* branch offsets (I'm not sure but I think Jeff told me of efforts
on the binutils side).
* yesterday we discussed something which Florian tells me is called
"contification" and which I think could be done reasonably easily
for functions with known local scope. Florian thinks it's expensive
(it probably is) so we may want -mmitigate-rop=strong options at
some point.
* Further out, symbolic addresses are a remaining problem that would
require work throughout the toolchain and could be expensive to
address.
Also useful would be better tools to detect possibly exploitable
sequences. Florian had some complaints about the reliability of the ones
we looked at, and I had some complaints about being lost in python
dependencies and not getting them installed in the first place.
Bernd
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.
