[llvm-dev] [RFC] Pagerando: Page-granularity code randomization

Per Larsen via llvm-dev llvm-dev at lists.llvm.org
Fri Oct 12 15:00:31 PDT 2018


>
> >> Pagerando is an improvement over ASLR; it is certainly not intended as

> >> a replacement for CFI. Pagerando instead complements CFI as a defense

> >> in depth by making it harder to reliably exploit unconstrained (legacy

> >> code w/o CFI) and weakly-constrained (e.g. those that require many

> >> targets w/CFI) branches.

> >
>Perhaps I am missing something, but if the low 12 bits of an address are
not modified between runs then, for the newer ROP attacks that perform
partial pointer >overwrites, this leaves you with 4 bits of useful
entropy.  If you try this attack on 100 devices then you will, on average,
compromise at least 12 of them.  That doesn’t >sound like it gives very
much security.

For context, David is referring to an academic study of the limits of code
randomization by Enes Göktaş and others:  Position-Independent Code Reuse:
On the Effectiveness of ASLR in the Absence of Information Disclosure
[0,1]. It is interesting research and complements the authors' earlier
limit studies of CFI. They conclude the paper with a recommendation to
combine CFI and code randomization which is exactly what we are proposing!

Stack massaging is a key step in PIROP and the idea is to coerce the
program to generate valid pointers by feeding the target process crafted
inputs. The adversary can then adjust the lower two bytes of the pointers
via partial pointer overwrites which gives him a position independent way
of addressing nearby gadgets. To understand the impact of pagerando and
ASLR, we can look at the first Asterisk exploit (Sec 4.1). The authors
trigger a stack corruption bug which causes 6 return addresses to be
spilled to the stack. It is not clear from the paper whether these point to
six unique return sites or not but we assume each address is unique for the
sake of argument.

ASLR:
    - an adversary can address 64KiB code relative to each pointer.
    - best case: ~64KiB gadget availability, worst case: 6*64KiB = 384KB
gadget availability.
    - 4 bits of entropy regardless of the number of return addresses to
overwrite

pagerando:
    - case 1: all return addresses point to the same page:
        + can address 4KiB of code worst case (vs 384KiB for ASLR)
        + must guess 4 bits of entropy for 1 pointer: 1/16 success rate
    - case 2: all return addresses point to different pages:
        + can address 6 * 4KiB code -> 24KiB gadget availability.
        + must guess 4 bits of entropy for 6 unrelated pointers  (in one
shot since PIROP avoids infoleaks): 2^4^6 = 2**24 = 1/16M.

To summarize: pagerando either limits the worst case gadget availability
down to ~6% of what adversaries have under ASLR. This makes it harder to
find "rare" gadgets (e.g. stack pivots). In case two, pagerando provides 20
more bits of entropy than ASLR. There are of course other cases between the
two extremes where you get some restriction of the gadget availability and
some increase in entropy.

Cheers,
Per

[0] Paywalled (unfortunately) print version:
https://ieeexplore.ieee.org/document/8406602
[1] Unrestricted, pre-print version:
https://www.portokalidis.net/files/pirop_eurosp18.pdf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181012/a94d0470/attachment.html>


More information about the llvm-dev mailing list