<div dir="ltr">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.</div><br><div class="gmail_quote"><div dir="ltr">On Fri, Oct 12, 2018 at 3:01 PM Per Larsen <<a href="mailto:perl@immunant.com">perl@immunant.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"></blockquote>>> Pagerando is an improvement over ASLR; it is certainly not intended as<br><blockquote class="gmail_quote" style="margin:0px 0.8ex;border-left:1px solid rgb(204,204,204);border-right:1px solid rgb(204,204,204);padding-left:1ex;padding-right:1ex"></blockquote>>> a replacement for CFI. Pagerando instead complements CFI as a defense<br><blockquote class="gmail_quote" style="margin:0px 0.8ex;border-left:1px solid rgb(204,204,204);border-right:1px solid rgb(204,204,204);padding-left:1ex;padding-right:1ex"></blockquote>>> in depth by making it harder to reliably exploit unconstrained (legacy<br><blockquote class="gmail_quote" style="margin:0px 0.8ex;border-left:1px solid rgb(204,204,204);border-right:1px solid rgb(204,204,204);padding-left:1ex;padding-right:1ex"></blockquote>>> code w/o CFI) and weakly-constrained (e.g. those that require many<br><blockquote class="gmail_quote" style="margin:0px 0.8ex;border-left:1px solid rgb(204,204,204);border-right:1px solid rgb(204,204,204);padding-left:1ex;padding-right:1ex"></blockquote>>> targets w/CFI) branches.<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
</blockquote>><br>>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.</div><div class="gmail_quote"><br></div></div></div></div></div></div></div></div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">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!</div><div dir="ltr"><br></div><div dir="ltr">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.</div><div dir="ltr"><br></div><div>ASLR:</div><div><div> - an adversary can address 64KiB code relative to each pointer.</div><div> - best case: ~64KiB gadget availability, worst case: 6*64KiB = 384KB gadget availability.</div></div><div> - 4 bits of entropy regardless of the number of return addresses to overwrite </div><div dir="ltr"><br></div><div dir="ltr"><div class="gmail_quote"><div><div>pagerando:</div><div> - case 1: all return addresses point to the same page:</div><div> + can address 4KiB of code worst case (vs 384KiB for ASLR)</div><div> + must guess 4 bits of entropy for 1 pointer: 1/16 success rate</div><div> - case 2: all return addresses point to different pages:</div><div> + can address 6 * 4KiB code -> 24KiB gadget availability.</div><div> + must guess 4 bits of entropy for 6 unrelated pointers (in one shot since PIROP avoids infoleaks): 2^4^6 = 2**24 = 1/16M.</div></div><div> </div><div>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.</div><div><br></div><div>Cheers,</div><div>Per</div><div><br></div><div>[0] Paywalled (unfortunately) print version: <a href="https://ieeexplore.ieee.org/document/8406602" target="_blank">https://ieeexplore.ieee.org/document/8406602</a></div><div>[1] Unrestricted, pre-print version: <a href="https://www.portokalidis.net/files/pirop_eurosp18.pdf" target="_blank">https://www.portokalidis.net/files/pirop_eurosp18.pdf</a></div></div></div></div></div></div></div></div></div>
</blockquote></div>