[PATCH] Insert random noops to increase security against ROP attacks (llvm)

[Stephen Crane]

It seems to me that this discussion centers on the difference in
granularity between ASLR and finer-grained alternatives, and what this
buys us.

ASLR is great because it makes attacks significantly harder -- by
which I mean successful exploits now require another step which is not
possible in all applications and makes the attack more brittle. An
attacker must now find the base address of the library they wish to
reuse. However, as Andrei mentioned, this can be done by disclosing
(or brute-forcing) the contents of any known pointer into the library,
such as a function pointer. If I know that a struct on the stack will
contain a pointer to some function and the application has a stack
buffer overread, I can disclose that function address. It is then
trivial to compute the base address of the library containing this
function and reuse all code from that library. Modern ASLR bypasses in
the wild do exactly this.

Finer-grained diversity extends this so that disclosing that function
pointer will not immediately expose the library for reuse. Since the
contents of the code is also randomized, an attacker must then
disclose enough of the actual code segment to find gadgets to reuse,
rather than data from the stack or heap. This requires an arbitrary
memory read primitive, which is a stronger and harder to find tool
than confined memory reads in the stack or heap. I'm highly doubtful
this is possible without a client-side scripting exploit.

I've added a few more comments below:

On Tue, Jan 6, 2015 at 3:38 PM, PaX Team <pageexec at gmail.com> wrote:
> On 5 Jan 2015 at 20:40, Chandler Carruth wrote:
>
>> On Mon, Jan 5, 2015 at 8:27 PM, PaX Team <pageexec at gmail.com> wrote:
>>
>> > what i question is whether this 'harder' property exists
>> > at all, and even if it does, in what situation it holds exactly.
>> >
>>
>> You have already stated at least one circumstance where it exists: where
>> things are not restartable (above some limit) or where the other
>> requirements of BROP aren't satisfied.
>
> in those situations it's not the property of nop insertion but that of
> the attacked system. put another way, other methods as simple as ASLR
> also achieve the same level of security in those cases.

Yes, I agree. ASLR is sufficient to prevent BROP, when deployed
"properly." I hope the existence of BROP makes server admins think
twice about ignoring service crashes. However, this is orthogonal to
diversity in general.

re other techniques: I completely agree with Chandler, the initial
choice of NOP insertion was simply an engineering issue. I would
actually recommend using function shuffling along with a small bit of
something finer grained to make sure that function contents are
randomized. This can be added, this patch is not the end of the line
here.

Schedule randomization, specifically, cannot be applied as generally
as NOP insertion, since some code offers little opportunity for
scheduling at all. In addition, it's not performance-neutral either.
However, the plan is to add scheduling as another technique, along
with any others people want.

- stephen