[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 18 Nov 2015 04:57:18 +0300
From: Solar Designer <solar@...nwall.com>
To: Bernd Schmidt <bschmidt@...hat.com>
Cc: oss-security@...ts.openwall.com, Jeff Law <law@...hat.com>,
Florian Weimer <fweimer@...hat.com>
Subject: Re: Fwd: x86 ROP mitigation
On Tue, Nov 17, 2015 at 05:24:26PM +0100, Bernd Schmidt wrote:
> 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.
Thank you!
I'd like more detail on the plan of dealing with function epilogues, if
there is a plan for that.
I'm not sure if this fits under:
> * Look into an idea Florian had for improving stack-protector
> epilogues.
or if that's (more likely) something entirely different.
What I mean is that function epilogues are useful gadgets, are common
(probably more so than e.g. computed branches coming from "switch"
statements), and appear to be difficult to deal with (preferably,
efficiently and not breaking the ABI) - or do you have an idea? I think
this aspect may very well be key to determining whether the entire
effort is worthwhile or not.
There's also an in-between option: if the security benefits are minimal
(and possibly non-existent), we might want to include zero runtime
performance impact changes only (e.g., renaming a chain of registers may
be OK, but introducing extra reg-reg move instructions would not be OK).
The result would be code with fewer usable gadgets (which might or might
not be any better security-wise, depending on threat model) that runs
just as fast.
Alexander
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.
