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

[Vlad Tsyrklevich via llvm-dev]

My largest issue with this scheme is that it's fundamentally a very complex
high-overhead mitigation requiring full platform support to be effective
which (IMO) is only useful for the least interesting targets: small system
services. It's not applicable to applications that can be meaningfully
attacked using data-only attacks (like kernels or hypervisors), or that
include in-process compilers (e.g. most browsers [excluding Edge, though
it's out-of-process JIT could also be attacked with this scheme]).  This is
completely ignoring attacks on the scheme itself, where effectiveness will
inevitably run up against memory constraints and other platform-specific
issues. Expecting adoption of a such a heavyweight mitigation for that
small benefit seems unrealistic to me and I'm not convinced it's worth the
cost.

On Fri, Oct 12, 2018 at 3:01 PM Per Larsen <perl at immunant.com> wrote:

> >> 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/335c6772/attachment-0001.html>