arXiv:1909.09294v1 [cs.CR] 20 Sep 2019 ASLR hl tespoieuraitcoehaslaiguesw users leaving overheads unrealistic provide others while inject code primitive preventing models role early the were eesbie ihteitouto fsmlsi e effec yet simplistic of introduction the with subsided were itmspormcd gis tef noetcd snippe code Innocent itself. against code program victim’s la ngm nsgt al ntejunytruhthe through journey the [ in attacks injection Early code jungle, sight. n landscape with attack in vulnerabilities endgame corruption memory clear of jungle lenging urnesaepsil oaheea rcia otto cost practical a at this achieve With to NGINX). possible deployment. encourage on low are SPEC) (4.4% have guarantees on M to applications (5.5% design, compute-intensive scalability real-world both and and in overhead performance average shows evaluation rcig acigcss n eoyoeha.M overhead. memory and need costs, minimizes further one-time disclosure; patching sharing memory or code prevent tracking, enabling stack continuous and shadow entwining eXecute and than supported (XoM) hardware of rather Memory use the scalable, while diversification and reactive sharing scalabi character and key code performance, security, embrace techniques: defense simultaneously of to efforts refocuses randomization otk hi hne omiti efrac expectations performance maintain to chances their take to in design narrow too defense being coverage, pragmatic defend comprehensive provide in on data-only to losing-their-way tunneled fail and costs, have BROP to all h seem at to re-use JIT-ROP, techniques code defense from attacks, As complexity techniques. in defense keep o evolved widely-adopted manner, them making utilitarian few forefront, and the the in elegant scalability an and in performance t so Notably, did attacks. techniques (ROP) programming return-oriented and uha oer-s.Cd eueatcs like attacks, (ROP) re-use Code programming re-use. code as such igemmr icouevleaiiy SRmvdto moved randomization ASLR grained vulnerability, disclosure memory single t applications code for position-independent method it. compilation for utilize default pushed the become this to sharing, upholdi code and code all ratio keeping cost-to-benefit of ASLR’s while of section Because code intact. executable an of address called [ (DEP) Prevention Execution Data like techniques in(E)adAdesSaeLyu admzto (ASLR) Randomization Layout Space Address and (DEP) tion qiaeto aiiu ala n ntae i mem- via initiated these weaponizat and locating code combat and payload To vulnerabilities. malicious corruption ory a of equivalent rsn a optn otne otug hog chal- a through trudge to continues computing day Present idn htcas-rie SRcudb yasdb a by bypassed be could ASLR coarse-grained that Finding Abstract epeetM present We hsqikyrfcsdefrsaantsrne adversari stronger against efforts refocused quickly This [ gadgets 23 hitpe Jelesnianski Christopher ,[ ], ARDU Dfnetcnqe uha aaEeuinPreven- Execution Data as such techniques —Defense 24 ignaTech Virginia with r eupsdt construct to repurposed are , ehiu htipoe ernoiainand re-randomization improves that technique ,[ ], eosrtsta togadsaal security scalable and strong that demonstrates 54 iesfiaini civdb implementing by achieved is diversification gadgets ARDU ,[ ], .I I. aigCd ernoiainPatclwt M with Practical Re-randomization Code Making [ 74 i admzn h xctbecode executable the randomizing via 79 NTRODUCTION an , n e-nolb [ ret-into-libc and ] ,wscetdt btuttebase the obstruct to created was ], ntefis place, first the in ndmn ytmwd re- system-wide on-demand ignaTech Virginia iwoYom Jinwoo gadget-chains return-oriented coarse-grained 75 16 ,uiiea utilize ], ,[ ], 52 18 iy Our lity. ,[ ], ARDU Some . ,[ ], scope, illing 63 -only istics eof ne the , . hese fine- tive 53 ion ing ion ing ng ]. ed es as ts, ’s o o ] SRiefcie ycletn drse n repeatedly and addresses collecting By ineffective. ASLR ol aehrwr upr i ne eoyProtection Memory Intel via support hardware have would huhcd ol o edrcl edvaXM tcould it XoM, via read directly be not could code Though i hrdcd eodn [ reloading code shared via itaiigmmr i h s fETmd n memory any made EPT of use the via memory virtualizing orsteatce orva h nievldeeual co executable valid entire Snow the Additionally, reveal region. to attacker sp the JIT-ROP boards vulnerabilities, disclosure memory exploiting es(P)[ (MPK) Keys eue orva oepgsdrn utm sin as stil runtime during (JIT-ROP) could pages programming heap) code return-oriented reveal and to stack used (via be disclosures memory indirect edn ftecd eina nRaatr[ Readactor in as region prevent code completely the “resistant”, of or reading reads code destructive [ ment ees ehiust eedb n en eesr and alive. necessary jungle means the any of by out defend get to techniques defense protected vulnera leak. still if memory and even any thereafter to static sufficient remains not code XoM; simply under is once randomizing cra involve a attacks launch [ inference reads to code less gadgets Other enough attack. reuse leak code and ASLR de-randomize to Xo that recently fewer until leaving and be not Tagging resources, would It infancy. system user. the its hog for resources and in expensive was JIT- access time against effective that While at (EPT). XoM ROP, Tables Page Extended chosen. be making will code version program which of unpredictable versions switch- it two randomly by between JIT-ROP, preventing execution as of ing well as capable ROP technique traditional ASLR both [ fine-grained Isomeron fly. only the on the chains bounda gadget application ROP an construct within and code JIT’ed reading of capable pointer code patching or tracking u a for not and processes into sharing few background code the supporting indexing of scalable, one is via is that Oxymoron defenses functions note, To (RaTTle). accessing leaving table w protected and references present, code labels all gadgets replacing [ unique all pointers Oxymoron code of protecting exposed. on coverage completely gadgets full some have not do [ eino h cl fisrcin [ instructions of scale the on region tl eddcdvia techniques deduced be still oetoogl ur eoyadrsrc cest finding ( to “resilient” access either restrict was XoM and gadgets. memory guard thoroughly more 67 hnwoMin Changwoo ignaTech Virginia vni oewsrnoie tvr n granularity, fine very at randomized was code if Even tti on,atcsbcm oefire intimidating fierce, more became attacks point, this At (XoM) Memory eXecute-only ,o eoypgs[ pages memory or ], 57 ,a ela npaecd admzto IR [ (IPR) randomization code in-place as well as ], RP[ BROP . 38 ,[ ], 50 44 n iia rtcini Rv- [ ARMv7-M in protection similar and ] ,alcto rce [ oracles allocation ], 26 neec tak n de-randomization and attacks inference tlzdgnrlzdsakcahreading crash stack generalized utilized ] 22 rgnSaeUniversity State Oregon .Hwvr ntuto displace- instruction However, ]. tal. et 76 Re-randomization ARDU .Teeatcssoe that showed attacks These ]. enjnJang Yeongjin a hnipeetdto implemented then was 47 [ 77 e.g. ,[ ], rsne JIT-ROP a presented ] 66 57 esnye[ Heisenbyte , evn fine-grained leaving , ,o obegadgets zombie or ], ,bscbok [ blocks basic ], 32 nbe code enables 22 just-in-time yusing by ] focused ] 78 34 )via ]) was ] sing ring 67 34 20 ing ble ith sh- de M ry s. ], ], ]. l to become too volatile to reliably craft attacks, rendering any comprehensive security guarantees. MARDU builds on insight leaked knowledge or weaponized code stale and incorrect, thus that thresholds like time intervals as in Shuffler and CodeAr- thwarting attacks. Currently, it is assumed that most attacks are mor or leaked-data-amount in ReRanz are a security loophole carried out remotely or require I/O system calls to engage. To and a performance shackle in re-randomization; MARDU does counter this, some works opt to trigger via a time interval, not rely on a threshold whatsoever in its design. This lets ideally shorter than the network round-trip latency [29],[37], MARDU completely side-step the no-win trade-off between [88], while others use known “code re-use relevant” events security and performance. Instead, MARDU borrows the event such as fork() [61] or I/O system calls [25],[84]. However, trigger design but pairs it with XoM violations. Using XoM, this assumption does not paint the entire picture of the ROP MARDU provides complete prevention of JIT-ROP protecting attack landscape. Defenses that utilize a threshold whether via against both variations of remote JIT-ROP as well as local JIT- time, such as Shuffler [88] and CodeArmor [29], or via leaked- ROP, compared to TASR which can only defend against the bytes as in ReRanz [84], are vulnerable to inevitably faster former, with almost zero overhead by using Intel MPK XoM. low-profile attacks as attacks continue to evolve. Therefore MARDU also combines XoM with trampolines by covering it can be reasoned that using an interval is simply not a them from read access while also completely decoupling the comprehensive metric and that the concept of using a threshold function entry and the function body in memory; unlike in is a liability. CodeArmor, this makes it impossible to infer and obtain ROP TASR [25] does not rely on a threshold, expecting attackers gadgets in the middle of a function from a leaked code pointer. write() usage of I/O system calls like . While they do prevent MARDU keeps performance and scalability at its forefront. remote JIT-ROP that use I/O system calls, TASR cannot pre- MARDU does not require expensive code pointer tracking vent memory disclosure within the application boundary [72]. and patching like TASR, nor does MARDU incur significant These re-randomization techniques forgo expensive execute- overhead from continuous re-randomization triggered by over- only memory, and instead pair randomization with protecting conservative time intervals or benign I/O system calls as in code pointers. Early re-randomization works such as Run- Shuffler and ReRanz, respectively. Additionally, while TASR timeASLR [61] and TASR [25] use mutable code pointer shows a very practical average overhead of 2.1%, it has approaches to ideally perturb a significant amount of live code, been reported by Shuffler [88] and ReRanz [84] that TASR’s but this comes with an equally significant performance cost overhead against a more realistic baseline (not using compiler (e.g., 30-50% in TASR [84],[88]) associated with pointer flag -Og) is closer to 30-50% overhead. Finally, MARDU is tracking and patching at re-randomiztion, severely limiting the designed to both support code sharing and not require the use effective re-randomization frequency possible. of any additional system resources (e.g., background threads Immutable code pointer approaches such as CodeArmor, as used in numerous works [25],[29],[37],[84],[88]) with Shuffler, and ReRanz are much more lightweight in terms the help of Linux kernel memory management and leveraging of tracking and patching. Although CodeArmor uses segmen- its own calling convention. To summarize, this paper makes tation (e.g., %gs) with offsetting, this technique still allows the following contributions: for ROP gadgets as well as function pointers to be reached • ROP attack & defense analysis. Our background §II (e.g., f+o == %gs:f+o, where f is an immutable code pointer describes the four prevalent ROP attacks that challenge cur- and o is an offset). Trampoline and indirection tables, used rent works, including JIT-ROP, code-inference, low-profile, by Shuffler and ReRanz, respectively, constrain this loophole and code pointer offsetting attacks. In addition, we describe to only full-function code reuse (e.g., allow only the case of the bottom-line security implications for each attack. With f+o == f’, where f’ is another function in the trampoline); this, we classify and exhibit current state-of-the-art defenses completely eliminating full-function code reuse and data- standings on three fronts: security, performance, and scala- oriented programming [49] is ongoing research. bility. Our findings show most defenses are not as secure or Regrettably, no current re-randomization techniques take as practical as expected against current ROP attack variants. into consideration the scalability of their approaches; support for code sharing has been forgotten, and the prevalence of • MARDU defense framework. We present the design of multi-core has excused the reliance on per-process background MARDU in §IV, a comprehensive ROP defense technique threads. In short, re-randomization is not as impenetrable capable of addressing all currently known ROP attacks. and competitive as initially thought. Current work has shown • Scalability and shared code support. MARDU creates that making a secure, practical, and scalable ROP defense and uses a new calling convention in order to be able to technique is challenging. Even if recent defenses have made both leverage a shadow stack and minimize the overhead of some headway through the jungle, most still lack effective pointer tracking. This calling convention is also what enables comprehensiveness in security for the system resource de- shared code (e.g., libraries) to be even more secure, able mands they require in return (both CPU and memory); these to be re-randomized by any host process and maintain the factors are prime showstoppers for deployment. integrity for the rest of the entire system. To the best of our In this paper, we introduce MARDU to refocus defense tech- knowledge, MARDU is the first framework capable of this. nique design, showing that it is possible to embrace the core • Evaluation & open source prototype. We implement a fundamentals of performance and scalability, while ensuring prototype of MARDU based on LLVM and Linux kernel. We
2 evaluate and analyze MARDU in §VI with compute-intensive does not protect code from read access including fine-grained benchmarks as well as real-world applications. MARDU’s ASLR techniques is susceptible to this attack. overhead for compute-intensive benchmarks is 5.5% on Security implications: Techniques failing to protect code average (geometric mean) and its worst-case overhead is from read access allows code-reuse attacks to be launched 18.3%. We will open source MARDU for the community to regardless of code randomization granularity. explore other defense mechanisms and build upon our work. 2) Load-time Randomization with XoM: In response to II. CODE LAYOUT (RE-)RANDOMIZATION A1 (JIT-ROP), several research projects protect code from In this section, we present a background on existing code read access via destructive read memory [78] or execute- layout re-randomization techniques. To help understand the only memory [21],[27],[29],[32],[33],[41],[70],[78], attack and defense arms race, we classify code randomization [87]. Systems with destructive read [78] allow code pointer techniques into two categories: load-time randomization and leaks to occur, but trigger intended localized code corruption continuous re-randomization. once a read attempt is made, such that code-reuse attacks To start with, we describe two attacks, A1 (JIT-ROP) and A2 following the read will fail to execute the expected code by the (BROP), aimed to defeat load-time code randomization. Next, attacker. Systems with execute-only memory (XoM) [21],[27], we describe how continuous re-randomization techniques defy [29],[32],[33],[41],[70],[78],[87] aim to fundamentally A1 and A2 by analyzing design elements of the techniques. block all read attempts of program code by removing read Specifically, we categorize continuous re-randomization tech- permissions from the code area. Applying these techniques niques by its re-randomization triggering condition (i.e., either prevent attackers from gaining knowledge about code contents, based on the system call history or timing threshold) and the and thereby, nullifying A1. However, leaving the code layout semantics of storing code pointers (i.e., tracking pointers or fixed after load-time randomization makes these techniques use an indirect, immutable function index). The reason for susceptible to the following attack. focusing on those two categories is that these design elements A2: Blind ROP (BROP) and code inference attacks. Even greatly affect the security, performance, and scalability of with protecting code from read access (i.e., XoM), load-time techniques. Finally, we compare and contrast each technique randomizations still are susceptible to BROP [26] and/or other regarding three aspects, security, performance, and scalabil- code content inference attacks [69],[76]. Although these ity. Particularly for illustrating attack resilience, we present attacks do not read code directly, attackers may accumulate two attacks, A3 (low-profile JIT-ROP) and A4 (code pointer information about the code contents by conducting probing offsetting), to which existing re-randomization techniques are on the code many times because code layout will never susceptible. Regarding scalability, we report the requirement change after it is loaded and shuffled. In particular, BROP is of additional CPU usage for re-randomization and whether a clone-probing attack that infers code contents via observing shared code layout is possible among multiple processes. differences in execution behaviors such as timing or program In summary, Table I illustrates the characteristics of each output. Other attacks [69],[76] defeat destructive code read defense technique by randomization category, attack resilience, defenses [78],[87] by inferring code contents from a small and performance and scalability factors, and we describe these fraction of a code read and then weaponizing inferred code. in detail in the following. Security implications: Maintaining a fixed layout over A. Attacks against Load-time Randomization crash-probing or read access to code allows inferring Load-time code randomization techniques suffer from at- code contents indirectly, and thereby, attackers can still tacks A1 (JIT-ROP) and A2 (BROP, etc.). In the following, learn the code layout and launch code-reuse attacks. we describe characteristics of techniques and attacks. 1) Load-time Randomization without XoM: Code layout randomization techniques so-called coarse-grained ASLR [79] B. Continuous Re-randomization Defeating A1 & A2 or fine-grained ASLR [22],[31],[34],[47],[48],[54],[57], In response to A1 (JIT-ROP) and A2 (BROP, etc.), contin- [67],[86], depending on the granularity of layout random- uous re-randomization techniques [25],[29],[37],[42],[61], ization, fall into this category of code layout randomization. [84],[88] aim to defeat attacks by continuously shuffling code These techniques randomize the code layout only once, usually (and data) layouts at runtime to make information (code or when code is loaded into memory. After code is loaded code addresses) leaks or code probing done before shuffling and shuffled, its layout never changes during the lifetime of useless. the program. The following attack can defeat the security To illustrate the internals of re-randomization techniques guarantee of load-time randomization techniques. in a nutshell, we describe the core design elements of re- A1: Just-in-time ROP (JIT-ROP). An attacker with arbitrary randomization by categorizing them into two, based on their memory read capability may launch JIT-ROP [77] by interac- design elements: 1) Re-randomization triggering condition and tively performing memory reads to disclose one code pointer. 2) Code pointer semantics. This disclosure can be used to then leap frog and further Re-randomization triggering condition. Existing continuous disclose other addresses to ultimately learn the code contents re-randomization techniques trigger their randomization based in memory. Any load-time code randomization technique that on the following two conditions.
3 Security Performance Scalability Types Defenses Gran. A1 A2 A3 A4 Perf. Avg. Worst Code Sharing No Addi. Process Fine-ASLR [31], [47], [48], [54], [57], [67], [86] Fine × × N/A × X 0.4% 6.4% × X Load-time ASLR Oxymoron [22] Coarse × × N/A × X 2.7% 11% X X Isomeron [34] Fine N/A × 19% 42% × ×
Readactor/Readactor++ [32], [33] Fine × N/A X 8.4% 25% × X Load-time+XoM LR 2 [27] Fine × N/A X 6.6% 18% × X kRˆ X [70] Fine × N/A X 2.32% 12.1% × X
RuntimeASLR [61] Coarse × N/A × × N/T N/T X X TASR [25] Coarse × × × 2.1%† 10.1%† × × Re-randomization ReRanz [84] Fine × X 5.3% 14.4% × × Shuffler [88] Fine × × 14.9% 40% × × CodeArmor [29] Coarse × × × 3.2% 55% × ×
Our Approach MARDU Fine X 5.5% 18.3% X X TABLE I: Classifications of ASLR-based code-reuse defenses. Gray highlighting emphasizes the attack (A1-A4) that largely invalidated each type of defense. indicates the attack is blocked by the defense. (attack-resistant). × indicates the defense is vulnerable to that attack. indicates the attack is not blocked but is still mitigated by the defense (attack-resilient). X indicates the defense meets performance/scalability requirements. × indicates the defense is unable to meet performance/scalability requirements. N/A in the column A3 indicates that the attack is not applicable to the defense due to lacking of re-randomization, and N/T in the column Performance indicates that either SPEC CPU2006 or perlbench is not tested. Specifically in the column A1, indicates that the defense cannot prevent the JIT-ROP attack within the application boundary that does not use system calls; in the column A4, × indicates that an attack may reuse both ROP gadgets and entire functions while indicates that an attack can only reuse entire functions. † Note that in TASR the baseline performance is a binary compiled with -Og, necessary to correctly track code pointers. Previous work [84], [88] reported performance overhead of TASR using regular optimization (-O2) binary is ≈30-50%. MARDU provides strong security guarantees with low performance overhead and good system-wide scalability compared to existing re-randomization approaches. • Timing: Techniques [29],[88] shuffle the layout periodi- design, leaking a code pointer will tell the attacker only the cally by setting a timing window for layout randomization. semantics of referring to a function (i.e., function index in For example, Shuffler [88] triggers re-randomization every the trampoline) but not about the code layout. 50 msec, and CodeArmor [29] can set re-randomization • An offset to the code address as code pointer: Code period as low as 55 µsec. pointers store an offset from the (randomized) base address • System-call history: Techniques [25],[61],[84] shuffle the of the layout. This design is also intended for avoiding layout based on the history of the program’s previous system pointer tracking by having an immutable offset from the call invocations, e.g., after invoking fork() [61] or when random version address for referring to a function, as in write() (leak) is followed by read() (exploit) [25],[84]. CodeArmor [29]. At re-randomization, updating code layout only requires updating the random version base address, Code pointer semantics. Existing continuous re- and does not require any update of pointers. With this randomization techniques use the following three different design, leaking a code pointer will tell the attacker the types of code pointer semantics. offset to select a function no matter how the code layout • Code address as code pointer: Code pointers store the is randomized. actual addresses. In this case, leaking a code pointer lets the attacker have knowledge about code address. Therefore, C. Attacks against Continuous Re-randomization techniques in this category [25],[42] require tracking of code pointers (or all pointers) at runtime, which is compu- Continuous re-randomization techniques suffer from two tation expensive, to update their values after randomizing attacks (A3 and A4) that we define in this section. the code (and data) layout. For instance, TASR [25] shows A3: Low-profile JIT-ROP. This is class of attacks does very high performance overhead (30-50%) especially for I/O- not trigger re-randomization either by completing the attack intensive applications, such as web servers [84],[88]. quickly or without requiring I/O system calls. As the trigger • Function trampoline address as code pointer: Code for layout re-randomization, Existing defenses utilize one of pointers store a function table index [88] or the address of a timing [29],[37],[42],[88], amount of transmitted data by function trampoline [84]. This design avoids the expensive output system calls [84], or I/O system call boundary [25] pointer tracking in order to enhance the performance of re- as the trigger for layout re-randomization. Therefore attacks randomization techniques. Instead of tracking and updating within the application boundary, such as code-reuse attacks code pointers, techniques in this category setup a function in Javascript engine where both information-leak followed by table, which stores all function addresses of the program, control-flow hijacking attack may conclude faster than the re- and store an index of the table in the code pointer to randomization timing threshold or not interact with I/O system refer a function. After re-randomization and re-locating call, can bypass these triggering conditions. The code layout the code layout, the techniques update only the function may remain unchanged within the given interval, and thereby, table while all code pointers remain immutable. With this an attacker may launch JIT-ROP to unchanged code layout.
4 Security implications: An attack may be completed (execve(), ld-linux, etc.), thus attackers cannot intervene within a defenses pre-defined randomization time interval to perform any attack before the program starts. or without involving any I/O system call invocation. In such a case, basing the re-randomization trigger on IV. MARDU DESIGN timing or system call history allows attackers bypass re- randomization and launch A1 (JIT-ROP) successfully. We begin by the design overview of MARDU (§IV-A) and then detail MARDU compiler (§IV-B) and kernel (§IV-C). A4: Code pointer offsetting. Even with re-randomization, techniques might be susceptible to a code pointer offsetting A. Overview attack if code pointers are not protected from having arithmetic operations applied by attackers [25],[29]. An attacker may This section presents the overview of MARDU, along with trigger a vulnerability to apply arithmetic operations to an its design goals, challenges, and outlines its architecture. existing code pointer. For example, suppose a code pointer 1) Goals: Understanding how the attack landscape and p points to a function f(), and altering the value of p by existing mitigations fit together, our goal in designing MARDU adding an offset o could make p point another code address is to shore up the current state-of-the-art to enable a practical p+o. Particularly, in techniques directly using code address [25] code randomization. More specifically, our design goals are as or code offset [29], p+o could be even a ROP gadget in f() if follows: the attacker knows the gadgets offset o beforehand. Ward et Security. No prior solutions provide a comprehensive defense al. [85] has recently demonstrated that this attack is possible against existing attacks (see §II). Systems with only load- against TASR. time ASLR are susceptible to leaking code-content (A1) and Security implications: Maintaining a fixed code layout letting attackers infer code-content (A2). Systems applying across re-randomizations and not protecting code pointers re-randomization are still susceptible to low-profile attacks lets attackers perform arithmetic operations over pointers, (A3) and code pointer offsetting attacks (A4). MARDU aims allowing launching other ROP gadgets. at either defeating or significantly limiting the capability of attackers in launching code-reuse attacks spanning from A1 to A4 to provide best-effort security against existing attacks. III. THREAT MODEL AND ASSUMPTIONS Performance. Many prior approaches [29],[32],[33],[88] We build MARDU based on the following assumptions. demonstrate decent runtime performance in average cases (< Attacker’s capability: 10 %, e.g., < 3.2 % in CodeArmor); however, they also show evidence of a few scenarios that are remarkably slow (i.e., > • Arbitrary read/write. Attackers can perform arbitrary 55 %, see listed numbers in Worst column in Table I). We memory read/write (if the address is readable/writeable) in design MARDU to run with an acceptable average overhead a target process by exploiting software vulnerabilities in the (≈ 5 %) with minimal performance outliers across a variety victim program. With this capability, attackers may launch of application types. attacks A1–A4 on an unprotected system. Scalability. Most proposed exploit mitigation mechanisms • Local brute-force attacks. We assume that all attack have overlooked the impact of required additional system attempts are run in a local machine. In this regard, attacks resources, such as memory or CPU usage, which we consider a may be performed any number of times within a short time scalability factor. This is crucial for applying a defense system- period (e.g., within a millisecond). This assumption gives the wide, and is even more critical when deploying the defense capability of launching attacks A1–A4 without triggering re- in the pay-as-you-go pricing Cloud. Oxymoron [22] is the randomization in prior systems [25],[29],[42],[84],[88]. only defense that allows code sharing of randomized code. No System and trusted computing base: advanced re-randomization defenses support code sharing thus • ⊕ ⊕ XoM (R X) and DEP (W X). We assume that the they require significantly more memory. Additionally, most userspace of the system does not have any memory region re-randomization defenses [29],[84],[88] require per-process that is both readable and executable. Likewise, we assume background threads, which not only cause additional CPU that the userspace of the system does not have any memory usage but also contention with the application process. As region that is both writable and executable. a result, approaches requiring per-process/thread background • Trusted hardware and no physical access. We assume threads show significant performance overhead as the number all hardware is trusted and attackers do not have physical of processes increases. For example, Shuffler [88] shows access. Particularly, we trust Intel Memory Protection Keys around 55% performance overhead when four NGINX workers (MPK) [50], a mechanism that provides eXecute-Only Mem- (plus four Shuffler threads) run on two cores with 50 ms ory (XoM), and we regard attacks to CPU (side-channel shuffling interval. attacks, e.g., Spectre [55], Meltdown [59]) to be out of Therefore, to apply MARDU system-wide, we design scope. MARDU to not require significant additional system resources, • Trusted kernel and program loading. We trust the for instance, additional processes/threads or significant addi- OS kernel and the loading/linking process of the program tional memory.
5 libc.so) upon exit. This re-randomizes all processes using the same executables (e.g., libc.so of all processes, including other workers of the NGNIX server, will be immediately re- randomized). Scalability: On-demand re-randomization. MARDU re- randomizes code only when suspicious activity is detected. MARDU considers any probing on code memory and program crash as suspicious activity and efficiently detects it using eXecute-Only-Memory (XoM). This design is advantageous because MARDU needs neither per-process background threads nor re-randomization interval unlike prior re-randomization ap- proaches. Particularly, MARDU re-randomization is performed Fig. 1: Overview of MARDU in the context of a crashing process, thereby not affecting the performance of other normal running processes. 2) Challenges: It is challenging to achieve all of aforemen- tioned goals. One naive approach is to mix all good defenses Performance: Immutable code pointers. The above de- from existing approaches but such an approach fails to meet scribed design decisions for scalability also help reduce per- the goal because requirements for enabling each defense could formance overhead. In addition, MARDU neither tracks nor conflict. Hence, we list challenges in achieving our goals in encrypts code pointers so it does not mutate code pointers the following. upon re-randomization. While this design choice minimizes Tradeoffs in security, performance, and scalability. An performance overhead, other security features (e.g., XoM, example of the tradeoff between security and performance trampoline, and shadow stack) in MARDU ensure the com- is having fine-grain ASLR with re-randomization. Although prehensive ROP defense. such an approach can defeat A4, systems cannot apply such Security: Detecting suspicious activities. MARDU considers protection because the re-randomization must finish quickly to any process crash or code probing attempt as a suspicious meet the performance goal and also defeat A3. An example activity. MARDU’s use of XoM makes any code probing at- of the tradeoff between scalability and performance is having tempt trigger process crash and system-wide re-randomization. a dedicated process/thread for performing re-randomization. Therefore, MARDU counters direct memory disclosure attacks However, this results in a drawback in scalability by requiring as well as code inference attacks requiring initial code prob- more CPU time in the entire system. Therefore, a good design ing [69],[76]. To implement XoM, we use Intel MPK [50] so must find a breakthrough to meet all of aforementioned goals. our XoM design does not impose any runtime overhead unlike Conflict in code-diversification vs. code-sharing. Layout virtualization-based designs. re-randomization requires diversification of code layout per Security: Preventing code & code pointer leakage. In ad- process, and this affects the availability of code-sharing. The dition to system-wide re-randomization, MARDU is designed status quo is that code sharing cannot be applied to any to minimize the leakage of code and code pointers. Besides existing re-randomization approaches, and this makes the XoM, we use three techniques. First, MARDU applications defense unable to scale to protect many-process applications. always go through a trampoline region to enter into or return Although Oxymoron [22] enables both diversification and from a function. Thus, only trampoline addresses are stored sharing of code, it does not consider re-randomization, nor in memory (e.g., stack and heap) while non-trampoline code use a sufficient randomization granularity (page-level), which pointers remain hidden. MARDU does not randomize where is insufficient against A4. the trampoline region is so MARDU does not need to track 3) Architecture: We design MARDU to make a break- and patch code pointers in memory upon re-randomization. through beyond tradeoffs in security, performance, and scal- Second, MARDU performs fine-grained function-level random- ability, which satisfies all three aspects and becomes practical. ization within an executable (e.g., libc.so) to completely We introduce our approach for each aspect below: disconnect any correlation between trampoline addresses and Scalability: Sharing randomized code. MARDU manages code addresses. This provides high entropy (i.e., roughly n! the cache of randomized code in the kernel, which is capable where n is the number of functions), so it is not feasible of being mapped to multiple userspace processes and is to succeed BROP [26] without any crash. Also, unlike re- not readable from userspace. Thus, it does not require any randomization approaches that rely on shifting code base additional memory. addresses [25],[29],[61], MARDU is not susceptible to Scalability: System-wide re-randomization. Since code is code pointer offsetting attack (A4). Finally, MARDU stores shared between processes in MARDU, per process random- return addresses–precisely, trampoline addresses for return–in ization, which is CPU intensive, is not required; rather a a shadow stack; the shadow stack stores only return addresses single process randomization is sufficient for the entire system. and is hidden under a segmentation register in x86. This design For example, once a worker process of NGNIX web server makes stack pivoting practically infeasible. crashes, it re-randomizes all its mapped executables (e.g., Design overview. As shown in Figure 1,MARDU is composed
6 of compiler and kernel components. The MARDU compiler replaces call and ret instructions with functionally equivalent jmp’s to the trampoline region and generates code to store return addresses in a shadow stack. MARDU compiler gener- ates PC-relative code so randomized code can be shared by multiple processes. Also, the compiler generates and attaches additional metadata to binaries for efficient patching of PC- relative addressing code upon (re-)randomization. The com- piler separates data from code pages to prevent false-positive XoM violations, from MARDU applications attempting to read inter-mixed data in protected code regions. The MARDU kernel is responsible for choreographing the runtime when a MARDU executable is launched. The kernel extracts and loads the executable’s compiler-generated meta- data into a cache to be shared by multiple processes. This data is then used by MARDU for first load-time randomization as well as re-randomization. The randomized code is cached and shared by multiple processes; while allowing sharing, each process will get a different random virtual address space for the shared code. MARDU kernel prevents read operations of Fig. 2: Illustrative example executing a MARDU-compiled function the code region including the trampoline region using XoM foo(), which calls a function bar() and then returns. so trampoline addresses do not leak information about non- trampoline code. Whenever a process crashes (e.g., XoM jumps to a call trampoline; an instrumented ret directly jumps to the return trampoline address at the current top of the violation), MARDU kernel re-randomizes all associated shared code so all relevant processes are re-randomized to thwart an shadow stack. The base address of the MARDU shadow stack attacker’s knowledge immediately. is randomized by ASLR and is hidden in segment register %gs, which cannot be modified in userspace and will never B. MARDU Compiler be stored in memory. Therefore, it is infeasible to know the MARDU compiler generates a binary able to 1) hide its code shadow stack base address without causing a program crash. pointers, 2) share its randomized code among processes, and We additionally reserve one register, %rbp, to use exclusively 3) run under XoM. To this end, MARDU uses its own calling as a stack top index of a shadow stack in order to avoid costly convention using a trampoline region and shadow stack. memory access. 1) Code Pointer Hiding: Trampoline. MARDU hides Running example. Figure 2 is an example of executing code pointers without paying for costly runtime code pointer a MARDU-compiled function foo(), which calls a function tracking. The key idea for enabling this is to split a binary bar() and then returns. Every function call and return goes into two regions in process memory: trampoline and code through trampoline code which stores the return address to regions (as shown in Figure 2 and Figure 3). A trampoline a shadow stack, of which base address is hidden in register is an intermediary call site that moves control flow securely %gs. The body of foo() is entered via its call trampoline to/from a function body, protecting the XoM hidden code 1 . Before foo() calls bar(), the return trampoline address region. There are two kinds of trampolines: call and return is stored to the shadow stack–each call site has one return trampolines. As their names imply, a call trampoline is respon- trampoline returning to the next instruction of the call site. sible for forwarding control flow from an instrumented call Control flow then jumps to bar()’s trampoline 2 , which will to the code region function entry, while a return trampoline jump to the function body of bar() 3 . bar() returns to the is responsible for returning control flow semantically to the address in the top of the shadow stack, which is the return caller. Each function has one call trampoline to its function trampoline address 4 . Finally, the return trampoline returns entry, and each call site has one return trampoline returning to the instruction following the call in foo() 5 . to the following instruction of the caller. Since trampolines 2) Enabling Code Sharing among Processes: PC-relative are stationary, MARDU does not need to track code pointers addressing. To enable sharing, MARDU compiler generates upon re-randomization because only stationary call trampoline PC-relative (i.e., position-independent) code so code can be addresses are exposed to memory. shared amongst processes that load the same code in different Shadow stack. Unlike the x86 calling convention using virtual addresses. The key challenge here is how to incorporate call/ret to store return addresses on the stack, MARDU PC-relative addressing with randomization.MARDU randomly instead stores all return addresses in a shadow stack and leaves places code (at function granularity) while trampoline regions data destined for the regular stack untouched. Effectively, this are stationary. This means any code using PC-relative address- protects all backward-edges. An instrumented call pushes ing must be correspondingly fixed up once its randomized a return trampoline address to the shadow stack and then location is decided. In Figure 2, all jump targets between
7 the trampoline and code, denoted in yellow rectangles, are PC-relative and must be fixed. Also, all data addressing instructions are PC-relative (e.g., accessing global data, GOT, etc.) and also must be fixed. Fixup information for patching. With this policy, it is necessary to keep track of these instructions to patch them properly during runtime. To make the runtime patching process simple and efficient, MARDU compiler generates additional metadata into the binary that describes exact locations for patching and their file-relative offset. This fixup information makes the patching as simple as just adjusting PC-relative offsets for given locations within analyzing instructions (see Figure 3). Since displacement in PC-relative addressing is 32 bits in size in x86-64 architecture, ±2 GB is the maximum offset from the %rip supported by this addressing mode. We Fig. 3: Memory layout of two MARDU processes: websrv (top elaborate on the patching process in §IV-C2. left) and dbsrv (top right). The randomized code in kernel (0xffffffff811f7000) is shared by multiple processes, which is Supporting a shared library. A call to a shared library is mapped to its own virtual base address (0x7fa67841a000 for websrv treated the same as a normal function call to preserve the and 0x7f2bedffc000 for dbsrv). code pointer hiding property; that is, MARDU refers to the call trampoline for the shared library call via PLT/GOT. It first calls 1) Process Memory Layout: Figure 3 illustrates the memory the PLT (Procedure Linkage Table) via a trampoline, which layout of two MARDU processes, websrv (top left) and dbsrv jumps to an external function whose address is not known at (top right). MARDU compiler generates a PC-relative binary link time and left to be resolved by the dynamic linker. The with trampoline code and fixup information 1 . When the result of dynamic symbol resolution is a function address in binary is first loaded to be mapped to a process, MARDU the call trampoline of the external library, and it is stored in a kernel first extracts all MARDU metadata–described in §IV-B2– in the binary and associates it on a per-file basis with the GOT (Global Offset Table) for caching. While MARDU does not specifically protect GOT, we assume that GOT is already binary’s inode structure. After extracting metadata, MARDU protected using MPK [36],[62]. has the information it needs to perform load-time randomiza- tion 2 . Note that load-time randomization and run-time re- Overhead of sharing. MARDU’s sharing mechanism does randomization follow the exact same procedure. MARDU first not have noticeable runtime overhead as PC-relative code is generates a random offset to set apart the code and trampoline already mandatory to enable ASLR. In addition, the overhead regions and then places functions in a random order (i.e., a of runtime patching is negligible because MARDU avoids random permutation) within the code region. Once functions “stopping the world” when patching the code to maintain are placed, MARDU then uses the cached MARDU metadata to internal consistency compared to other approaches. perform patching of offsets within both trampoline and code 3) Enabling Execute-Only-Memory: Finally, to run code regions, updating PC-relative jmp targets and data locations to with XoM, MARDU compiler ensures code and data are seg- preserve program semantics. Finally, the randomized code is regated in different pages. Compilers sometimes intermingle now semantically correct and can be cached and mapped to data within .text code section as an optimization. However, multiple applications 3 . if this data is attempted to be read during runtime, an XoM violation will be raised. As previous work [32] reported, we 2) Fine-Grain Code Randomization: Allocating a virtual found that Clang intermingles code and data only for jump code region. MARDU kernel randomizes the binary when tables so we disable generating jump tables in .text section. the binary is mapped with executable permissions. For each randomized binary, the MARDU kernel allocates a 2 GB 2 C. MARDU Kernel virtual address region (Figure 3 2 ), which will be mapped to userspace virtual address space with coarse-grained ASLR ARDU M kernel randomizes code at load-time and runtime. 3 It maps already-randomized code, if it exists, to the address (Figure 3 3 ) . MARDU kernel positions the trampoline code space of a newly fork-ed process. When an application at the end of the virtual address region and returns the start address of the trampoline as a result of mmap. The trampoline crashes, MARDU re-randomizes all mapped binaries associated with the crashing process and reclaims the previous random- address will remain static throughout program execution even ized code from the cache after all processes are moved to a after re-randomization. newly re-randomized code. MARDU prevents direct reading Randomizing the code within the virtual region. To achieve ARDU of randomized code from userspace using XoM. M 2 1 We note that, for the unused region, we map all those virtual addresses initializes a shadow stack whenever clone-ing a task . to a single abort page that generate a crash when accessed to not to waste real physical memory and also detect potential attack attempts. 1In this paper, a term task denotes both process and thread as the convention 3We choose 2 GB because in x86-64 architecture PC-relative addressing in Linux kernel. can refer ±2 GB range from %rip.
8 a high entropy, MARDU kernel uses fine-grained randomiza- will raise SIGBUS and trigger re-randomization. Unlike EPT- tion within the allocated virtual address region. Once the based XoM designs [32],[78], our MPK-based design does trampoline is positioned, MARDU kernel randomly places the not impose runtime overhead. non-trampoline code within the virtual address region (sized 5) On-Demand Re-randomization: Triggering re- 2 GB); MARDU decides the random offset between the code randomization. An unsuccessful probing of the attack and the trampoline regions. Once the code region is decided, causes the process to crash. Therefore, when a process crashes MARDU permutes functions within the code region to further MARDU triggers re-randomization of all binaries mapped to increase entropy. As a result, trampoline addresses do not the crashing process. Since MARDU re-randomization thwarts leak information on non-trampoline code and an adversary attacker’s knowledge (i.e., each attempt is an independent cannot infer any actual codes’ location from the system trial), an adversary must succeed in her first try without information, /proc/
9 Fig. 4: Re-randomization procedure in MARDU. Once a new re-randomized code is populated 1 , MARDU kernel maps new code and trampoline in order 2 , 3 . This makes threads crossing the new trampoline migrate to the newly re-randomized code. After it is guaranteed that all threads are migrated to the new code, MARDU reclaims the old code 4 . Unlike previous continuous per-process re-randomization approaches, our re-randomization is time-bound, almost zero overhead, and system-wide. the new code. Since MARDU permutes at function granularity, standard library implementation for Linux, because glibc can- %rip translation is merely adding an offset between the old not be compiled with Clang. We manually modified 164 LOC and new function locations. in musl libc to make assembly functions (e.g., math functions Summary. Our re-randomization scheme has three nice prop- and atomic intrinsics) follow the MARDU calling convention erties: time boundness of re-randomization, almost zero over- by adding C wrapper functions so MARDU compiler can head of running process, and system-wide re-randomization. automatically identify and instrument them. The re-randomization is guaranteed to finish at most within A. MARDU Compiler one scheduling quantum (e.g., 1 msec) once the newly random- ized code is exposed 3 . That is because MARDU migrates Trampoline. MARDU compiler is implemented as backend runnable tasks at system call and scheduling boundary. If target-ISA (x86) specific MachineFunctionPass. This pass another process crashes in the middle of re-randomization, instruments each function body as described in §IV-B. MARDU will not trigger another re-randomization until the Re-randomizable code. To force all instructions to use current randomization finishes. However, as soon as the new PC-relative addressing, MARDU compiler uses -fPIC. As randomized code is populated 1 , a new process will map an optimization of our trampoline design, MARDU compiler the new code immediately. Therefore, the old code cannot be uses a register %rbp for stack top index of a shadow stack. observed more than once. MARDU kernel populates a new To force the compiler to relinquish the use of the register randomized code in the context of a crashing process. All other %rbp, MARDU compiler uses -fomit-frame-pointer. To save runnable tasks only additionally perform reference counting space in PC-relative addressing of code and data, the x86 or translation of %rip to the new code. Thus, its runtime architecture provides various jmp instruction variants varying overhead for runnable tasks is negligible. To the best of our in offset size from 1, 2, or 4 bytes. In MARDU, to maximize knowledge, MARDU is the first system to perform system-wide entropy and be able to use the full span of memory within re-randomization allowing code sharing. our declared 2 GB virtual address region, MARDU compiler 6) Shadow Stack: To hide the shadow stack location, uses -mrelax-all to force the compiler to always emit full MARDU first reserves a 2 GB of virtual memory space with 4-byte displacement in the executable. Since all PC-relative abort pages and then chooses a base address to map the instructions have 4-byte wide displacement, MARDU kernel shadow stack. Additionally, no direct reference to the shadow can freely place any function to within 2 GB address range stack is available in memory because MARDU accesses it without any restriction. To completely separate code and data via a dedicated register, %gs, which will not disclose the for XoM, MARDU compiler disables jump tables in .text base address of the shadow stack. As a result, an adversary section using -fno-jump-tables. must brute-forcingly guess its base address; any crash in such attempt will trigger re-randomization, which invalidates all B. MARDU Kernel prior information gained. When a new task is created (clone), Shadow stack. Currently the maximum shadow stack size the MARDU kernel allocates a new shadow stack and copies is set to 64 KB; when a task is created, MARDU kernel parent’s shadow stack to its child. creates a 2 GB virtual address space region and randomly place its shadow stack in that region, guarded by inaccessible V. IMPLEMENTATION pages (to hide the shadow stack). To maximize performance, We implemented MARDU on the Linux x86-64 platform. MARDU implements a compact shadow stack without compar- MARDU compiler is implemented using LLVM 6.0.0 and isons [28]. MARDU kernel is implemented based on Linux kernel 4.17.0 Secure random number generation. To perform randomiza- modifying 3549 and 4009 lines of code (LOC), respectively. tion, MARDU uses cryptographically secure random number We used musl libc 1.1.20 [13], which is a fast, lightweight C generator in Linux kernel based on hardware random sources
10 such as rdrand/rdseed instructions in modern Intel architec- re-randomization (A3–A4, §VI-A2). Then, to illustrate the tures. effectiveness of MARDU for a wider class of code-reuse attacks beyond ROP, we present results of the residual attack C. Limitation of Our Prototype surface analysis using the threat model of NEWTON [82] Assembly Code. MARDU does not support inline assembly (§VI-A3). as it difficult to figure how to deal with module-level inline MARDU Security Summary: assembly as was present in musl libc; however, this could be • vs.A1: Execute-only memory blocks the attack. resolved with further engineering. Instead, we manually added • vs.A2: Re-randomization blocks any code inference via crash. C wrapper functions so MARDU compiler adds trampolines • vs.A3: Execute-only memory and a large search space (2 GB which complies to MARDU calling convention. dummy mappings) block JIT-ROP and crash-resistant prob- ing. Setjmp and exception handling. MARDU uses a shadow • vs.A4: Trampolines decouple function entry from function stack to store return addresses. Thus, functions such as setjmp, bodies blocking any type of code pointer offsetting; full longjmp, and libunwind that directly manipulate return ad- function code reuse of exported functions remains possible. dresses on stack are not supported by our current prototype. • vs.NEWTON: the same as A4. However, modifying these functions is straightforward because 1) Attacks against Load-Time Randomization: Against JIT- essentially our shadow stack is a variant of compact, register- ROP attacks (A1). MARDU asserts permissions for all code based shadow stack [28]. areas (both code and trampoline regions) as execute-only (via C++ support. Our prototype does not support C++ applica- XoM); thereby, an attacker with JIT-ROP capability cannot tions since we do not have a stable standard C++ library that read code contents directly. is musl-compatible. Therefore handling C++ exceptions and Against code inference attacks (A2). MARDU blocks code protecting vtables is out of scope. inference attacks, including BROP [26], clone-probing [61], VI. EVALUATION and destructive code read attacks [69],[76] via layout re- randomization triggered by an application crash or XoM We evaluate MARDU by answering these questions: violation. This mechanism effectively blocks A2 attacks by • How secure is MARDU, when presented against current known attacks on randomization? (§VI-A) preventing attackers from accumulating indirect information because every re-randomization renders all previously gathered • How much performance overhead does MARDU impose, particularly for compute-intensive benchmarks? (§VI-B) (if any) information regarding the code layout invalid. • How scalable is MARDU in a real-world network facing Hiding shadow stack. Attackers with arbitrary read/write server, particularly with concurrent processes, in terms capability (A1/A2) may attempt to leak/alter shadow stack of load time, re-randomization time, and memory used? contents if its address is known. Although the location of (§VI-C) the shadow stack is hidden behind the %gs register to prevent Applications. We evaluate the performance overhead and leakage of pointers, attackers may employ attacks that under- scalability of MARDU using SPEC CPU2006 and NGINX mine this sparse-memory based information hiding [35],[44], web server. The SPEC benchmark suite has various realistic [66]. To prevent such attacks, MARDU reserves a 2 GB virtual compute-intensive applications (e.g., gcc) which are ideal to memory space for the shadow stack (the same way MARDU see the worst-case performance overhead of MARDU. We allocates code/library space) and then chooses a random offset tested all 12 C language benchmarks; we excluded C++ to map the shadow stack; other pages in the remaining 2 GB benchmarks as our current prototype does not support it. space are mapped as an abort page that has no permissions. We choose SPEC CPU2006 over its newer version, SPEC Even assuming if an attacker is able to identify the 2 GB CPU2017, because SPEC CPU2006 has been popularly used region for the shadow stack using crash-less poking [44] or to show the performance overhead in many prior works. Input employing allocation oracles [66], they must also overcome size ref was used for all benchmarks. To test performance and the randomization entropy of the offset to get a valid address scalability of MARDU on a complex, real-world application, within this region; any incorrect probe will generate crash (due we ran NGINX, which is a widely utilized web server. We to abort pages), thereby, thwarting the attack. Consequently, the probability of successfully guessing the location of any configured NGINX as multi-process. We report the average of 31 four runs. valid shadow stack address is roughly one in 2 , practically Experimental setup. All programs are compiled with op- infeasible. timization -O2 and run on a 24-core (48-hardware threads) Entropy. MARDU applies both function-level permutation and machine equipped with two Intel Xeon Silver 4116 CPUs random start offset to provide high entropy to the new code (2.10 GHz) and 128 GB DRAM. layout. Specifically, MARDU permutes all functions in each executable and applies a random start offset to the code area A. Security Evaluation in 2 GB space for each randomization. Thus, randomization To evaluate the security of MARDU, we first analyze the entropy depends on the number of functions in the executable 31 resiliency of MARDU against existing attacker models against and the size of a code region (i.e., log2(n! · 2 ) where n load-time randomization (A1–A2, §VI-A1) and continuous is the number of functions). To give an idea of how much
11 Return address ROP gadget Func reuse MARDU Benchmark flow of a program (write constraints) as well as possible # call # i-call # gadgets # fn entry reduction (%) available gadgets in MARDU (target constraints), which will perlbench 13963 272 34371 1668 48606/50274 (96.7%) bzip2 277 56 1569 81 1902/1983 (95.9%) reveal what attackers can do under this threat model. In short, gcc 48096 518 89746 4318 138360/142678 (97.0%) mcf 77 3 513 33 593/626 (94.7%) MARDU allows only the reuse of exported functions via call milc 2104 7 3864 244 5975/6219 (96.1%) trampolines. gobmk 9521 48 37999 2477 47568/50045 (95.0%) hmmer 4237 12 9466 478 13715/14193 (96.6%) For write constraints, attackers cannot overwrite real code sjeng 1054 4 3110 139 4168/4307 (96.8%) libquantum 469 3 1686 107 2158/2265 (95.3%) addresses such as return addresses and code addresses in the h264ref 3118 372 14456 528 17946/18474 (97.1%) trampoline. MARDU only allows attackers to overwrite other lbm 70 3 394 26 467/493 (94.7%) sphinx3 2714 11 5628 326 8353/8679 (96.2%) types of pointer memory, e.g., object pointers and pointers to NGINX 5316 309 15434 1565 21059/22624 (93.1%) musl libc 4400 77 29743 3722 34220/37942 (90.2%) the call trampoline. For target constraints, attackers can reuse
Total 95416 1695 247979 15712 345090/360802 (95.6%) only the exported functions via call trampoline. Note that a function pointer is a reusable target in any re-randomization TABLE II: Potential attack surface and MARDU’s reduction in binaries. While a function call trampoline is a only reusable target techniques using immutable code pointers [29],[84],[88]. in MARDU, an attacker cannot infer ROP gadgets from the call Although MARDU allows attackers to reuse function pointers trampoline addresses. in accessible memory (e.g., a function pointer in a structure), such live addresses will never include real code addresses, such entropy MARDU provides, we take an example of 470.lbm in as a return address or real code address, and will be limited SPEC CPU2006, a case which provides the minimum entropy to addresses referencing call trampolines. Under these write in our evaluation. The program, which contains 26 functions and target constraints, inferring the location of ROP gadgets and is less than 64 KB in size, has 119.38 bits entropy. from code pointers (e.g., leaking code addresses or adding an Therefore, even for a small program, MARDU randomizes offset) is not possible. the code with significantly high entropy (119 bits) to render Residual attack surface. Table II presents potential code- attacker’s success rate for guessing the layout negligible. reuse attack surface of programs in this evaluation and how 2) Attacks against Continuous Re-randomization: Against much MARDU reduces such attack surface (i.e., possible code low-profile attacks (A3). MARDU does not rely on timing reuse targets in the program). For each program, we present nor system call history for triggering re-randomization. As the attack surface in three categories. a result, neither low-latency attacks nor attacks without in- • Direct calls (# call) and indirect calls (# i-call), which volving system calls are effective against MARDU. Instead, may leak return addresses to the regular stack. re-randomization is triggered and performed by any MARDU • ROP Gadgets (# gadgets), the main ingredient in construct- instrumented application process on the system that encounters ing a code re-use payload by being chained together to a crash (e.g., XoM violation). Nonetheless, a potential A3 make a valid attack. This data is obtained via running vector could be one that does not cause any crash during ROPgadget [73] on each benchmark binary. exploitation (e.g., attackers may employ crash-resistant prob- • Function entries (# fn entry) that can be used for whole ing [35],[39],[44],[56],[66]). In this regard, MARDU places function re-use attack. all code in execute-only memory with 2 GB mapped region. MARDU completely protects the first two categories (i.e., Such a stealth attack could only identify multiples of 2 GB return address and ROP gadget) using shadow stack and XoM, code regions and will fail to leak any fine-grained layout of respectively. Therefore, the remaining potential attack surface code or code addresses stored in trampolines. is function entry (i.e., call trampolines in MARDU). Evaluating Against code pointer offsetting attacks (A4). For code SPEC, musl libc, and NGINX, MARDU reduces access to pointers referring to call trampolines, attackers may attempt these sensitive fragments up to a max of 97.1% and 95.6% on to launch an A4 attack by adding/subtracting an offset to the average, constraining attackers to reuse only exported function pointer. To defend against such an attack, MARDU decouples entries. any correlation between trampoline function entry addresses and function body addresses (i.e., no fixed offset), so attackers B. Performance Evaluation cannot refer to the middle of a function for a ROP gadget Runtime performance overhead with SPEC CPU2006. without actually obtaining a valid function body address. Figure 5 shows the relative performance overhead of SPEC Additionally, the trampoline region is also protected with with MARDU compared to the unprotected baseline, compiled XoM, thus attackers cannot probe it to obtain function body with vanilla Clang. Overall, MARDU’s average overhead is addresses to launch A4. MARDU limits available code-reuse comparable to the fastest re-randomization systems. Notably, targets to only exported functions in the trampoline region. We MARDU worst-case overhead is significantly better than sim- analyze the residual attack surface of MARDU in Table II. ilar systems. The average overhead of MARDU is 5.5%, and 3) Viable Attacks in MARDU: Attack analysis with NEW- the worst-case overhead is 18.3% (perlbench); in comparison TON. To measure the boundary of viable attacks against to Shuffler [88] and CodeArmor [29], whose reported average MARDU, we present a security analysis of MARDU based on overheads are 14.9% and 3.2%, respectively, while their worst- the threat model set by NEWTON [82]. In this regard, we case overhead are 45% and 55%, respectively (see Table I). analyze possible writable pointers that can change the control This confirms MARDU is capable of matching if not slightly
12 20 C. Scalability Evaluation 15
10 Runtime performance overhead with NGINX. NGINX is configured to accommodate a maximum of 1024 connections 5 per processor, and its performance is observed according 0 to the number of worker processes. wrk [43] is used to Performance overhead (%) overhead Performance perlbenchbzip2 gcc mcf milc gobmk hmmersjeng libquantumh264reflbm sphinx3 geomean generate HTTP requests for benchmarking. wrk spawns the same number of threads as NGINX workers and each wrk thread sends a request for a 6745-byte static html. To see Fig. 5: Performance overhead of MARDU for SPEC CPU2006 the worst-case performance, wrk is run on the same machine 20 as NGINX to factor out network latency. Figure 7 presents Trampoline only (no shadow stack) Full Mardu (trampoline + shadow stack) the performance of NGINX with and without MARDU for 15 a varying number of worker processes. The performance 10 observed shows that MARDU exhibits very similar throughput
5 to vanilla. MARDU incurs 4.4%, 4.8%, and 1.2% throughput degradation on average, at peak (12 threads), and at saturation
Performance overhead (%) overhead Performance 0 perlbenchbzip2 gcc mcf milc gobmkhmmersjeng libquantumh264reflbm sphinx3geomean (24 threads), respectively. Note that Shuffler [88] suffers from the overhead from per-process shuffling thread. Even in their NGINX experiments with network latency (i.e., running a Fig. 6: Overhead breakdown for SPEC CPU2006 benchmarking client on a different machine), Shuffler shows 2500 15-55% slowdown. This verifies MARDU’s design that having
Mardu
2000 Vanilla the crashing process perform system-wide re-randomization,
rather than a per-process background thread as in Shuffler,
1500
scales better.
1000
© Load-time randomization overhead. We categorize load-
¨ §
¦ 500 B time to cold or warm load-time whether the in-kernel code
0 cache ( 2 in Figure 3) hits or not. Upon a code cache miss
¡ ¢£ ¤ ¥
4 12 (i.e., the executable is first loaded in a system), MARDU
# er processes performs initial randomization including function-level per- Fig. 7: Performance comparison of NGINX web server mutation, start offset randomization of the code layout, and loading & patching of fixup metadata. As Figure 8 shows, all C SPEC benchmarks showed negligible overhead averaging 95.9 improving the performance (especially worst-case) overhead, msec. gcc, being the worst-case, takes 771 msec; it requires the while casting a wider net in terms of known attack coverage, most overall fixups relative to other benchmarks (see Table III). compared to the current state-of-the-art. For NGINX, we observe that load time is constant (61 msec) Performance overhead breakdown. The two prominent for any number of specified worker processes. Cold load-time sources of runtime overhead in MARDU are trampolines and is roughly linear to the number of trampolines in Table III. the shadow stack. To understand how much runtime overhead Upon a code cache hit, MARDU simply maps the already- each code transformation imposes, we ran SPEC with two randomized code to a user-process’s virtual address space. different configurations: we first enabled only trampolines and Therefore we found that warm load-time is negligible. Note do not use a shadow stack (trampoline only in Figure 6), that, for a cold load-time of musl libc takes about 52 msec then we enabled both trampolines and the shadow stack (full on average. Even so, this is a one time cost; all subsequent MARDU in Figure 6). The performance overhead of both are warm load-time accesses of fetching musl libc takes below normalized to vanilla SPEC compiled with vanilla Clang. As 1 µsec, for any program needing it. Thus, load time can be Figure 6 shows, the major source of overhead is trampoline; largely ignored. trampolines incur 5.9% overhead on average, with the worst Re-randomization latency. Figure 9 presents the time taken cases being 15.8% and 14.2% of overhead, for perlbench to re-randomize all associated binaries of a crashing process. and h264ref, respectively. Note that MARDU’s shadow stack The time includes creating re-randomizing the code layout, overhead is negligible. The average difference comparing and reclaiming the old code ( 1 - 4 in Figure 4). To emulate MARDU trampolines with full MARDU is less than 0.3%, and an XoM violation, we killed the process with a SIGBUS signal in the noticeable gaps, adding less than 2% to MARDU in and measured the re-randomization time inside the kernel. The most cases compared to using MARDU trampolines only. This average latency of SPEC is 6.2 msec. The difference between is expected as MARDU uses a compact shadow stack with- load-time and re-randomization latency because MARDU takes out comparison epilogue. This implementation performs only advantage of the metadata being cached from load-time, this essential bookkeeping to utilize the shadow stack; skipping means no redundant file I/O penalty is incurred, giving this per- unnecessary epilogue micro-optimizations [28]. formance gain. To evaluate the efficiency of re-randomization
13
800 | milc sjeng gobmk
600 { z 18 18 18
500 y
^ _
x
w
400 \]
v u
300 t 12 12 12 r 10 10 10 200 q
o 8 8 8 k
oad-time rand (msec) 100
~ M
j 6
0 i
}
b g / s l h F n p 4
mcf milc hmmer sphinx3 a
8 G
4
9
) - 0 A I
m
N
5
H
*
. :
! 1
C J
O
6
+
K
" 2 2 2
;
2
D P
$
7
,
L
Q
<
E
%
3 R
= ef
& 0 0 0
S
>
'
e
erfor
?
(
@
f
d
c 1ms 1ms 1ms
` 10ms 10ms 10ms 100ms 100ms 100ms Fig. 8: Cold load-time randomization overhead 1000ms 1000ms 1000ms 20 Fig. 10: Overhead varying re-randomization frequency
15 Numbers of Fixups Binary Increase (bytes) Benchmark 10 CallTr. RetTr. PC-rel.addr Total Trampolines Metadata Total perlbench 1596 39174 62430 103200 1115136 2607559 3722695 5 bzip2 66 926 896 1888 17568 78727 96295
e-rand latency (msec) gcc 4015 118617 169067 291699 3074672 6276870 9351542 T 0 mcf 23 94 208 325 1824 19056 20880
perlbenchbzip2 gcc mcf milc gobmkhmmersjeng libquantumh264reflbm sphinx3nginx U
V milc 234 3531 7256 11021 110688 313620 424308
W X
Y gobmk 2388 22880 41632 66900 726176 3085208 3811384 Z
[ hmmer 452 5145 9925 15522 139216 574446 713662 sjeng 129 1368 5418 6915 58912 250234 309146 libquantum 97 1659 1424 3180 25952 93222 119174 Fig. 9: Re-randomization latency h264ref 508 5874 14824 21206 278240 714629 992869 lbm 16 75 260 351 1920 16549 18469 sphinx3 308 4958 8010 13276 103920 409814 513734 on multi-thread/multi-process applications, we measured the NGINX 1497 15004 18984 35485 416736 1309708 1726444 re-randomization latency with varying number of NGINX musl libc 4400 10009 7594 22003 192153 1238071 1430224 worker processes up to 24. We confirm that the latency is TABLE III: Breakdown of MARDU instrumentation consistent regardless of number of workers (5.8 msec on average with 0.5 msec of standard deviation). 14K trampolines and 7.6K fixups for PC-relative addressing, the total trampoline size is 190 KB and the amount of loaded Re-randomization overhead under active attacks. A good metadata is 1.2 MB (refer to Table III). Since MARDU supports re-randomization system should exhibit good performance not code sharing, only one copy of libc is needed for the entire only in its idle state but also under stress from active attacks. system. Our experimental setup at idle reported 310 processes To evaluate this, we stress test MARDU under frequent re- while a typical 2-core consumer laptop at idle reported 263 randomization to see how well it can perform, assuming a processes. Therefore a rough estimate of memory savings for scenario that MARDU is under attack. In particular, we mea- libc that MARDU provides compared to similar instrumenta- sure the performance of SPEC benchmarks while triggering tion that did not support code sharing is over ≈526-620 MB of frequent re-randomization. We emulate the attack by running still usable runtime memory. Furthermore, comparing to time- a background application, which continuously crashes at the based continuous re-randomization techniques such as Shuf- given periods: 1 sec, 100 msec, 50 msec, 10 msec, and 1 msec. fler [88] and CodeArmor [29] which almost always maintain SPEC benchmarks and the crashing application are linked with two copies of code, MARDU’s memory saving for libc is ≈1- the MARDU version of musl libc, forcing MARDU to con- 1.2 GB. Backes et al. [22] and Ward et al. [85] also highlighted stantly re-randomize musl libc and potentially incur perfor- the code sharing problem in randomization techniques and mance degradation on other processes using the same shared reported a similar amount of memory savings by sharing library. In this experiment, we choose three representative randomized code. Finally, note that the use of shadow stack benchmarks, milc, sjeng, and gobmk, that MARDU exhibits a does not increase runtime memory footprint because MARDU small, medium, and large overhead in an idle state, respectively. solely relocates return address from the normal stack to the Figure 10 shows that the overhead is consistent, and in fact, shadow stack. is very close to the performance overhead in the idle state observed in Figure 5. More specifically, all three benchmarks VII. DISCUSSION differ by less than 0.4% at a 1 sec re-randomization interval. When we decrease the re-randomization period to 10 msec Applying MARDU to binary programs. Although MARDU and 1 msec, the overhead is quickly saturated. Even at 1 msec requires access to source code, applying MARDU directly re-randomization frequency, the additional overhead is under to binary programs is possible. The job of the MARDU 6 %. These results confirm that MARDU provides performant compiler is to detect all indirect control transfers (call/ret) system-wide re-randomization even under active attack. and instrument such transfers to utilize trampolines. Such Runtime memory savings. While an upfront one-time cost instrumentation can be done at binary-level if each call/ret is paid for instrumenting with MARDU, the savings greatly can be precisely detected in a program. Applying MARDU outweigh this. To illustrate, we show a typical use case of to non-PC relative binary is challenging; however, position- MARDU in regards to shared code. musl libc is ≈800 KB independent executables (PIEs), are now the default code in size, instrumented is 2 MB. Specifically, musl libc has generation mode in gcc-7, which naturally use PC-relative
14 addressing. Therefore, MARDU should be practical enough to [6] Proceedings of the 2015 Annual Network and Distributed System Secu- adopt with little additional effort. rity Symposium (NDSS), San Diego, CA, Feb. 2015. [7] Proceedings of the 22nd ACM Conference on Computer and Communi- Full-function reuse attacks. Throughout our analysis, we cations Security (CCS), Denver, Colorado, Oct. 2015. show that existing re-randomization techniques that use a [8] Proceedings of the 36th IEEE Symposium on Security and Privacy function trampoline or indirection table, i.e., use immutable (Oakland), San Jose, CA, May 2015. [9] Proceedings of the 11th ACM Symposium on Information, Computer and (indirect) code pointer across re-randomization, cannot prevent Communications Security (ASIACCS), Xi’an, China, May–Jun. 2016. full-function reuse attacks. This also affects MARDU; although [10] Proceedings of the 2016 Annual Network and Distributed System Secu- limited to functions exposed in the trampoline, MARDU cannot rity Symposium (NDSS), San Diego, CA, Feb. 2016. [11] Proceedings of the 25th USENIX Security Symposium (Security), Austin, defend against an attacker reusing such exposed functions as TX, Aug. 2016. gadgets by leaking code pointers. We believe that this is a [12] Proceedings of the 37th IEEE Symposium on Security and Privacy limitation of using immutable code pointers, and one possible (Oakland), San Jose, CA, May 2016. . . solution to prevent these attacks could be pairing MARDU [13] “musl libc,” 2019, https://wiki musl-libc org/. [14] Proceedings of the 40th IEEE Symposium on Security and Privacy together with control-flow-integrity (CFI) [15],[30],[40],[45], (Oakland), San Francisco, CA, May 2019. [46],[60],[64],[65],[68],[71],[80],[81],[83],[89],[90] [15] M. Abadi, M. Budiu, U. Erlingsson, and J. Ligatti, “Control-flow or code-pointer integrity/separation (CPI/CPS) [58]. MARDU integrity,” in Proceedings of the 12th ACM Conference on Computer and Communications Security (CCS), Alexandria, VA, Nov. 2005. already provides backward-edge CFI via shadow stack, so [16] O. Aleph, “Smashing the stack for fun and profit,” http://www. shmoo. forward-edge CFI can also be leveraged to further reduce com/phrack/Phrack49/p49-14, 1996. available code-reuse targets. MARDU’s defense is orthogonal [17] Amazon, “Amazon EC2 C5 Instances,” 2019, https://aws.amazon.com/ to CFI, so applying both defenses can complement each other ec2/instance-types/c5/. [18] A. Anonimo, “Once upon a free ()..” Phrack Magazine, vol. 11, no. 57, to provide better security. However, completely eliminating 2001. full-function code reuse and data-oriented programming [49] [19] ARM, “ARM Compiler Software Development Guide: 2.21 Execute- . . . with low performance overhead and system-wide scalability is only memory,” 2019, http://infocenter arm com/help/index jsp?topic=/ com.arm.doc.dui0471j/chr1368698326509.html. still an open problem. [20] ARM Community, “What is eXecute-Only-Memory (XOM)?” july 2017, https : //community.arm.com/developer/ip - products/processors/b/ VIII. CONCLUSION processors-ip-blog/posts/what-is-execute-only-memory-xom. [21] M. Backes, T. Holz, B. Kollenda, P. Koppe, S. N¨urnberger, and J. Pewny, While current defense techniques are capable of warding “You can run but you can’t read: Preventing disclosure exploits in off current known ROP attacks, most designs must inherently executable code,” in Proceedings of the 21st ACM Conference on tradeoff well-rounded performance and scalability for their Computer and Communications Security (CCS), Scottsdale, Arizona, Nov. 2014. security guarantees. With this insight, we introduce MARDU,a [22] M. Backes and S. N¨urnberger, “Oxymoron: Making Fine-Grained Mem- novel on-demand system-wide re-randomization technique to ory Randomization Practical by Allowing Code Sharing,” in Proceedings combat code-reuse attacks. MARDU shows pragmatic defense of the 23rd USENIX Security Symposium (Security), San Diego, CA, Aug. 2014. design is indeed navigatable in the face of the jungle that the [23] S. Bhatkar, D. C. DuVarney, and R. Sekar, “Efficient techniques for code reuse attack landscape is. MARDU is the first code-reuse comprehensive protection from memory error exploits.” in Proceedings defense capable of code-sharing with re-randomization and of the 14th USENIX Security Symposium (Security), Baltimore, MD, Aug. 2005. thus allows scalability in an effort to focus on practicality. In [24] ——, “Address obfuscation: An efficient approach to combat a broad addition, by being able to re-randomize on-demand, MARDU range of memory error exploits.” in Proceedings of the 12th USENIX eliminates both the costly runtime overhead and the integral Security Symposium (Security), Washington, DC, Aug. 2003. [25] D. Bigelow, T. Hobson, R. Rudd, W. Streilein, and H. Okhravi, “Timely component of a threshold associated with continuous re- Rerandomization for Mitigating Memory Disclosures,” in Proceedings of randomization. Our evaluation verifies MARDU’s security guar- the 22nd ACM Conference on Computer and Communications Security antees against known attacker models and adequately quan- (CCS), Denver, Colorado, Oct. 2015. [26] A. Bittau, A. Belay, A. Mashtizadeh, D. Mazi`eres, and D. Boneh, tifies its high-level of entropy. Furthermore, MARDU’s per- “Hacking blind,” in Proceedings of the 35th IEEE Symposium on Security formance evaluation showcases its robustness when deployed and Privacy (Oakland), San Jose, CA, May 2014. with real-world applications derived from SPEC CPU2006 [27] K. Braden, L. Davi, C. Liebchen, A.-R. Sadeghi, S. Crane, M. Franz, averaging overhead of 5.5% as well as confirming scalability and P. Larsen, “Leakage-Resilient Layout Randomization for Mobile Devices,” in Proceedings of the 2016 Annual Network and Distributed in multi-process scenarios with NGINX web server, averaging System Security Symposium (NDSS), San Diego, CA, Feb. 2016. only 4.4% degradation. [28] N. Burow, X. Zhang, and M. Payer, “SoK: Shining Light on Shadow Stacks,” in Proceedings of the 40th IEEE Symposium on Security and REFERENCES Privacy (Oakland), San Francisco, CA, May 2019. [29] X. Chen, H. Bos, and C. Giuffrida, “CodeArmor: Virtualizing The [1] Proceedings of the 14th ACM Conference on Computer and Communi- Code Space to Counter Disclosure Attacks,” in Proceedings of the 2nd cations Security (CCS), Alexandria, VA, Oct.–Nov. 2007. IEEE European Symposium on Security and Privacy (Euro S&P), Paris, [2] Proceedings of the 33rd IEEE Symposium on Security and Privacy France, Apr. 2017. (Oakland), San Francisco, CA, May 2012. [30] Y. Cheng, Z. Zhou, Y. Miao, X. Ding, and R. H. Deng, “Ropecker: A [3] Proceedings of the 22th USENIX Security Symposium (Security), Wash- generic and practical approach for defending against rop attack,” Feb. ington, DC, Aug. 2013. 2014. [4] Proceedings of the 34th IEEE Symposium on Security and Privacy [31] M. Conti, S. Crane, T. Frassetto, A. Homescu, G. Koppen, P. Larsen, (Oakland), San Francisco, CA, May 2013. C. Liebchen, M. Perry, and A.-R. Sadeghi, “Selfrando: Securing the [5] Proceedings of the 23rd USENIX Security Symposium (Security), San tor browser against de-anonymization exploits,” Proceedings on Privacy Diego, CA, Aug. 2014. Enhancing Technologies, vol. 2016, no. 4, pp. 454–469, 2016.
15 [32] S. Crane, C. Liebchen, A. Homescu, L. Davi, P. Larsen, A.-R. Sadeghi, [50] Intel Corporation, “Intel 64 and IA-32 Architectures Software De- S. Brunthaler, and M. Franz, “Readactor: Practical Code Randomization veloper’s Manual,” 2019, https : //software.intel.com/en - us/articles/ Resilient to Memory Disclosure,” in Proceedings of the 36th IEEE intel-sdm. Symposium on Security and Privacy (Oakland), San Jose, CA, May [51] ——, “INTEL ® XEON ® SCALABLE PROCESSORS,” 2019, https:// 2015. www.intel.com/content/www/us/en/products/processors/xeon/scalable. [33] S. J. Crane, S. Volckaert, F. Schuster, C. Liebchen, P. Larsen, L. Davi, html. A.-R. Sadeghi, T. Holz, B. De Sutter, and M. Franz, “It’s a TRaP: [52] Jonathan Corbet, “x86 NX support,” 2004, https : //lwn.net/Articles/ Table Randomization and Protection Against Function-reuse Attacks,” 87814/. in Proceedings of the 36th IEEE Symposium on Security and Privacy [53] M. Kaempf, “Vudo malloc tricks. phrack magazine, 57 (8), august 2001.” (Oakland), San Jose, CA, May 2015. [54] C. Kil, J. Jun, C. Bookholt, J. Xu, and P. Ning, “Address space layout [34] L. Davi, C. Liebchen, A.-R. Sadeghi, K. Z. Snow, and F. Monrose, permutation (ASLP): Towards fine-grained randomization of commodity “Isomeron: Code Randomization Resilient to (Just-In-Time) Return- software,” in Proceedings of the Annual Computer Security Applications Oriented Programming,” in Proceedings of the 2015 Annual Network Conference (ACSAC), 2006. and Distributed System Security Symposium (NDSS), San Diego, CA, [55] P. Kocher, J. Horn, A. Fogh, , D. Genkin, D. Gruss, W. Haas, M. Ham- Feb. 2015. burg, M. Lipp, S. Mangard, T. Prescher, M. Schwarz, and Y. Yarom, [35] I. Evans, S. Fingeret, J. Gonzalez, U. Otgonbaatar, T. Tang, H. Shrobe, “Spectre attacks: Exploiting speculative execution,” in Proceedings of S. Sidiroglou-Douskos, M. Rinard, and H. Okhravi, “Missing the point the 40th IEEE Symposium on Security and Privacy (Oakland), San (er): On the effectiveness of code pointer integrity,” in Proceedings of Francisco, CA, May 2019. the 36th IEEE Symposium on Security and Privacy (Oakland), San Jose, [56] B. Kollenda, E. G¨oktas¸, T. Blazytko, P. Koppe, R. Gawlik, R. K. Konoth, CA, May 2015. C. Giuffrida, H. Bos, and T. Holz, “Towards Automated Discovery of [36] Fedora, “Hardening Flags Updates for Fedora 28,” 2018, https : // Crash-resistant Primitives in Binary Executables,” in Proceedings of the fedoraproject.org/wiki/Changes/HardeningFlags28. 47th International Conference on Dependable Systems and Networks [37] M. Gallagher, L. Biernacki, S. Chen, Z. B. Aweke, S. F. Yitbarek, M. T. (DSN), Denver, CO, Jun. 2017. Aga, A. Harris, Z. Xu, B. Kasikci, V. Bertacco, S. Malik, M. Tiwari, [57] H. Koo and M. Polychronakis, “Juggling the gadgets: Binary-level code and T. Austin, “Morpheus: A Vulnerability-Tolerant Secure Architecture randomization using instruction displacement,” in Proceedings of the Based on Ensembles of Moving Target Defenses with Churn,” in 11th ACM Symposium on Information, Computer and Communications Proceedings of the 24th ACM International Conference on Architectural Security (ASIACCS), Xi’an, China, May–Jun. 2016. Support for Programming Languages and Operating Systems (ASPLOS), [58] V. Kuznetsov, L. Szekeres, M. Payer, G. Candea, R. Sekar, and D. Song, Providence, RI, USA, Apr. 2019, pp. 469–484. “Code-Pointer Integrity,” in Proceedings of the 11th USENIX Symposium [38] R. Gawlik, B. Kollenda, P. Koppe, B. Garmany, and T. Holz, “Enabling on Operating Systems Design and Implementation (OSDI), Broomfield, client-side crash-resistance to overcome diversification and information Colorado, Oct. 2014. hiding.” in Proceedings of the 2016 Annual Network and Distributed [59] M. Lipp, M. Schwarz, D. Gruss, T. Prescher, W. Haas, A. Fogh, System Security Symposium (NDSS), San Diego, CA, Feb. 2016. J. Horn, S. Mangard, P. Kocher, D. Genkin, Y. Yarom, and M. Hamburg, [39] ——, “Enabling Client-Side Crash-Resistance to Overcome Diversifi- “Meltdown: Reading kernel memory from user space,” in Proceedings of cation and Information Hiding,” in Proceedings of the 2016 Annual the 27th USENIX Security Symposium (Security), Baltimore, MD, Aug. Network and Distributed System Security Symposium (NDSS), San Diego, 2018. CA, Feb. 2016. [60] Y. Liu, P. Shi, X. Wang, H. Chen, B. Zang, and H. Guan, “Transparent [40] X. Ge, W. Cui, and T. Jaeger, “Griffin: Guarding control flows using and efficient CFI enforcement with intel processor trace,” in Proceedings intel processor trace,” in Proceedings of the 22nd ACM International of the 23rd IEEE Symposium on High Performance Computer Architec- Conference on Architectural Support for Programming Languages and ture (HPCA), Austin, TX, Feb. 2017. Operating Systems (ASPLOS), Xi’an, China, Apr. 2017. [61] K. Lu, W. Lee, S. N¨urnberger, and M. Backes, “How to Make ASLR [41] J. Gionta, W. Enck, and P. Ning, “HideM: Protecting the Contents Win the Clone Wars: Runtime Re-Randomization,” in Proceedings of of Userspace Memory in the Face of Disclosure Vulnerabilities,” in the 2016 Annual Network and Distributed System Security Symposium Proceedings of the 5th ACM Conference on Data and Application (NDSS), San Diego, CA, Feb. 2016. Security and Privacy (CODASPY), San Antonio, TX, Mar. 2015. [62] Michael Larabel, “Glibc Rolls Out Support For Memory Protection [42] C. Giuffrida, A. Kuijsten, and A. S. Tanenbaum, “Enhanced Operating Keys,” 2017, https : //www.phoronix.com/scan.php?page = news item& System Security Through Efficient and Fine-grained Address Space Ran- px=Glibc-Memory-Protection-Keys. domization,” in Proceedings of the 21st USENIX Security Symposium [63] Microsoft Support, “A detailed description of the Data Execution (Security), Bellevue, WA, Aug. 2012. Prevention (DEP) feature in Windows XP Service Pack 2, [43] W. Glozer, “a HTTP benchmarking tool,” 2019, https://github.com/wg/ Windows XP Tablet PC Edition 2005, and Windows Server wrk. 2003,” 2017, https : //support.microsoft.com/en - us/help/875352/ [44] E. G¨oktas¸, R. Gawlik, B. Kollenda, E. Athanasopoulos, G. Portokalidis, a-detailed-description-of-the-data-execution-prevention-dep-feature-in. C. Giuffrida, and H. Bos, “Undermining Information Hiding (and What [64] B. Niu and G. Tan, “Modular control-flow integrity,” in Proceedings of to Do about It),” in Proceedings of the 25th USENIX Security Symposium the 2014 ACM SIGPLAN Conference on Programming Language Design (Security), Austin, TX, Aug. 2016. and Implementation (PLDI), Edinburgh, UK, Jun. 2014. [45] J. Grossklags and C. Eckert, “τCFI: Type-Assisted Control Flow In- [65] ——, “Per-input control-flow integrity,” in Proceedings of the 22nd ACM tegrity for x86-64 Binaries,” in Proceedings of the 21th International Conference on Computer and Communications Security (CCS), Denver, Symposium on Research in Attacks, Intrusions and Defenses (RAID), Colorado, Oct. 2015. Heraklion, Crete, Greece, Sep. 2018. [66] A. Oikonomopoulos, E. Athanasopoulos, H. Bos, and C. Giuffrida, [46] Y. Gu, Q. Zhao, Y. Zhang, and Z. Lin, “Pt-cfi: Transparent backward- “Poking holes in information hiding.” in Proceedings of the 25th USENIX edge control flow violation detection using intel processor trace,” in Security Symposium (Security), Austin, TX, Aug. 2016. Proceedings of the 7th ACM Conference on Data and Application [67] V. Pappas, M. Polychronakis, and A. D. Keromytis, “Smashing the Security and Privacy (CODASPY), Scottsdale, AZ, Mar. 2017. gadgets: Hindering return-oriented programming using in-place code [47] J. Hiser, A. Nguyen-Tuong, M. Co, M. Hall, and J. W. Davidson, “ILR: randomization,” in Proceedings of the 33rd IEEE Symposium on Security Where’d My Gadgets Go?” in Proceedings of the 33rd IEEE Symposium and Privacy (Oakland), San Francisco, CA, May 2012. on Security and Privacy (Oakland), San Francisco, CA, May 2012. [68] ——, “Transparent ROP Exploit Mitigation Using Indirect Branch [48] A. Homescu, S. Brunthaler, P. Larsen, and M. Franz, “librando: Transpar- Tracing,” in Proceedings of the 22th USENIX Security Symposium ent Code Randomization for Just-in-Time Compilers,” in Proceedings of (Security), Washington, DC, Aug. 2013. the 20th ACM Conference on Computer and Communications Security [69] J. Pewny, P. Koppe, L. Davi, and T. Holz, “Breaking and Fixing (CCS), Berlin, Germany, Oct. 2013, pp. 993–1004. Destructive Code Read Defenses,” in Proceedings of the 12th ACM [49] H. Hu, S. Shinde, S. Adrian, Z. L. Chua, P. Saxena, and Z. Liang, Symposium on Information, Computer and Communications Security “Data-oriented programming: On the expressiveness of non-control data (ASIACCS), Abu Dhabi, UAE, Apr. 2017, pp. 55–67. attacks,” in Security and Privacy (SP), 2016 IEEE Symposium on. IEEE, [70] M. Pomonis, T. Petsios, A. D. Keromytis, M. Polychronakis, and V. P. 2016, pp. 969–986. Kemerlis, “kRˆ X: Comprehensive Kernel Protection against Just-In-
16 Time Code Reuse,” in Proceedings of the 12th European Conference and Deployable Continuous Code Re-Randomization,” in Proceedings on Computer Systems (EuroSys), Belgrade, Serbia, Apr. 2017. of the 12th USENIX Symposium on Operating Systems Design and [71] A. Prakash, X. Hu, and H. Yin, “vfGuard: Strict Protection for Virtual Implementation (OSDI), Savannah, GA, Nov. 2016. Function Calls in COTS C++ Binaries.” in Proceedings of the 2015 [89] C. Zhang, T. Wei, Z. Chen, L. Duan, L. Szekeres, S. McCamant, D. Song, Annual Network and Distributed System Security Symposium (NDSS), and W. Zou, “Practical control flow integrity and randomization for San Diego, CA, Feb. 2015. binary executables,” in Proceedings of the 34th IEEE Symposium on [72] R. Rudd, R. Skowyra, D. Bigelow, V. Dedhia, T. Hobson, S. Crane, Security and Privacy (Oakland), San Francisco, CA, May 2013. C. Liebchen, P. Larsen, L. Davi, M. Franz et al., “Address-Oblivious [90] M. Zhang and R. Sekar, “Control Flow Integrity for COTS Binaries,” Code Reuse: On the Effectiveness of Leakage Resilient Diversity,” in Proceedings of the 22th USENIX Security Symposium (Security), in Proceedings of the 2017 Annual Network and Distributed System Washington, DC, Aug. 2013. Security Symposium (NDSS), San Diego, CA, Feb.–Mar. 2017. [73] J. Salwan, “Ropgadget: Gadgets finder and auto-roper,” 2019, https:// github.com/JonathanSalwan/ROPgadget. [74] H. Shacham, “The geometry of innocent flesh on the bone: Return-into- libc without function calls (on the x86),” in Proceedings of the 14th ACM Conference on Computer and Communications Security (CCS), Alexandria, VA, Oct.–Nov. 2007. [75] ——, “The geometry of innocent flesh on the bone: Return-into-libc without function calls (on the x86),” in Proceedings of the 14th ACM Conference on Computer and Communications Security, Alexandria, VA, Oct.–Nov. 2007. [76] K. Z. Snow, R. Rogowski, J. Werner, H. Koo, F. Monrose, and M. Poly- chronakis, “Return to the Zombie Gadgets: Undermining Destructive Code Reads via Code Inference Attacks,” in Proceedings of the 37th IEEE Symposium on Security and Privacy (Oakland), San Jose, CA, May 2016. [77] K. Z. Snow, F. Monrose, L. Davi, A. Dmitrienko, C. Liebchen, and A.-R. Sadeghi, “Just-in-time Code Reuse: On the Effectiveness of Fine-grained Address Space Layout Randomization,” in Proceedings of the 34th IEEE Symposium on Security and Privacy (Oakland), San Francisco, CA, May 2013. [78] A. Tang, S. Sethumadhavan, and S. Stolfo, “Heisenbyte: Thwarting mem- ory disclosure attacks using destructive code reads,” in Proceedings of the 22nd ACM Conference on Computer and Communications Security (CCS), Denver, Colorado, Oct. 2015. [79] The PAX Team, “Address Space Layout Randomization,” 2003, https:// pax.grsecurity.net/docs/aslr.txt. [80] C. Tice, T. Roeder, P. Collingbourne, S. Checkoway, U.´ Erlingsson, L. Lozano, and G. Pike, “Enforcing Forward-Edge Control-Flow In- tegrity in GCC & LLVM,” in Proceedings of the 23rd USENIX Security Symposium (Security), San Diego, CA, Aug. 2014. [81] V. van der Veen, D. Andriesse, E. G¨oktas¸, B. Gras, L. Sambuc, A. Slowinska, H. Bos, and C. Giuffrida, “Practical context-sensitive CFI,” in Proceedings of the 22nd ACM Conference on Computer and Communications Security (CCS), Denver, Colorado, Oct. 2015. [82] V. van der Veen, D. Andriesse, M. Stamatogiannakis, X. Chen, H. Bos, and C. Giuffrdia, “The dynamics of innocent flesh on the bone: Code reuse ten years later,” in Proceedings of the 24th ACM Conference on Computer and Communications Security (CCS), Dallas, TX, Oct.–Nov. 2017. [83] V. van der Veen, E. G¨oktas, M. Contag, A. Pawoloski, X. Chen, S. Rawat, H. Bos, T. Holz, E. Athanasopoulos, and C. Giuffrida, “A tough call: Mitigating advanced code-reuse attacks at the binary level,” in Proceedings of the 37th IEEE Symposium on Security and Privacy (Oakland), San Jose, CA, May 2016. [84] Z. Wang, C. Wu, J. Li, Y. Lai, X. Zhang, W.-C. Hsu, and Y. Cheng, “Reranz: A Light-weight Virtual Machine to Mitigate Memory Disclo- sure Attacks,” in Proceedings of the 13th International Conference on Virtual Execution Environments (VEE), Xi’an, China, Apr. 2017. [85] B. C. Ward, R. Skowyra, C. Spensky, J. Martin, and H. Okhravi, “The Leakage-Resilience Dilemma,” in Proceedings of the 24th European Symposium on Research in Computer Security (ESORICS), Luxembourg, Sep. 2019. [86] R. Wartell, V. Mohan, K. W. Hamlen, and Z. Lin, “Binary stirring: Self-randomizing instruction addresses of legacy x86 binary code,” in Proceedings of the 19th ACM Conference on Computer and Communi- cations Security (CCS), Raleigh, NC, Oct. 2012. [87] J. Werner, G. Baltas, R. Dallara, N. Otterness, K. Z. Snow, F. Mon- rose, and M. Polychronakis, “No-execute-after-read: Preventing code disclosure in commodity software,” in Proceedings of the 11th ACM Symposium on Information, Computer and Communications Security (ASIACCS), Xi’an, China, May–Jun. 2016. [88] D. Williams-King, G. Gobieski, K. Williams-King, J. P. Blake, X. Yuan, P. Colp, M. Zheng, V. P. Kemerlis, J. Yang, and W. Aiello, “Shuffler: Fast
17