PACStack: an Authenticated Call Stack
Hans Liljestrand Thomas Nyman Lachlan J. Gunn University of Waterloo, Canada Aalto University, Finland Aalto University, Finland [email protected] thomas.nyman@aalto.fi [email protected] Jan-Erik Ekberg N. Asokan Huawei Technologies Oy, Finland University of Waterloo, Canada Aalto University, Finland Aalto University, Finland [email protected] [email protected]
Abstract Recent software-based shadow stacks show reasonable per- A popular run-time attack technique is to compromise the formance [10], but are vulnerable to an adversary capable control-flow integrity of a program by modifying function re- of exploiting memory vulnerabilities to infer the location of turn addresses on the stack. So far, shadow stacks have proven the shadow stack. To date, only hardware-assisted schemes, to be essential for comprehensively preventing return ad- such as Intel CET [29], achieve negligible overhead without dress manipulation. Shadow stacks record return addresses in trading off security. But employing such a custom hardware integrity-protected memory secured with hardware-assistance mechanism incurs development and deployment costs. or software access control. Software shadow stacks incur Recent ARM processors include support for pointer authen- high overheads or trade off security for efficiency. Hardware- tication (PA); a hardware extension that uses tweakable mes- assisted shadow stacks are efficient and secure, but require sage authentication codes (MACs) to sign and verify point- the deployment of special-purpose hardware. ers [4]. One initial use case of PA is the authentication of re- We present authenticated call stack (ACS), an approach turn addresses [45]. However, current PA schemes are vulnera- that uses chained message authentication codes (MACs). Our ble to reuse attacks, where the adversary can reuse previously prototype, PACStack, uses the ARM general purpose hard- observed valid protected pointers [35]. Prior work [35, 45] 1 2 ware mechanism for pointer authentication (PA) to implement and current implementations by GCC and LLVM mitigate ACS. Via a rigorous security analysis, we show that PACStack reuse attacks, but cannot completely prevent them. achieves security comparable to hardware-assisted shadow In this paper, we propose a new approach, authenticated stacks without requiring dedicated hardware. We demonstrate call stack (ACS), providing security comparable to hardware- that PACStack’s performance overhead is small (≈3%). assisted shadow stacks, with minimal overhead and without requiring new hardware-protected memory. ACS binds all return addresses into a chain of MACs that allow verification 1 Introduction of return addresses before their use. We show how ACS can be efficiently realized using ARM PA while resisting reuse Traditional code-injection attacks are ineffective in the pres- attacks. The resulting system, PACStack, can withstand strong ence of W⊕X policies that prevent the modification of exe- adversaries with full memory access. Our contributions are: cutable memory [49]. However, code-reuse attacks can alter • ACS, a new approach for precise verification of function the run-time behavior of a program without modifying any of return addresses by chaining MACs (Section4). its executable code sections. Return-oriented programming • PACStack, an LLVM-based realization of ACS using ARM (ROP) is a prevalent attack technique that corrupts function PA without requiring additional hardware (Section5). return addresses to hijack a program’s control flow. ROP can • A systematic evaluation of PACStack security, showing that be used to achieve Turing-complete computation by chain- its security is comparable to shadow stacks (Section6). ing together existing code sequences in the victim program. • Demonstrating that the performance overhead of PAC- To prevent ROP, return addresses must be protected when Stack is small (≈3%) (Section7). stored in memory. At present, the most powerful protection PACStack and associated evaluation code is available as open against ROP is using an integrity-protected shadow stack source at https://pacstack.github.io. that maintains a secure reference copy of each return ad- dress [1]. Integrity of the shadow stack is ensured by mak- 1https://gcc.gnu.org/onlinedocs/gcc/AArch64-Function- ing it inaccessible to the adversary either by randomizing its Attributes.html location in memory or by using specialized hardware [29]. 2https://reviews.llvm.org/D49793 2 Background 8 bits reserved bit 3 – 23 bits VA_SIZE bits
tag/PAC sign ext./PAC virtual address (AP) 2.1 ROP on ARM general purpose registers HK(AP, M) PA key (K) In ROP, the adversary exploits a memory vulnerability to manipulate return addresses stored on the stack, thereby al- 64-bit modifier (M) configuration register tering the program’s backward-edge control flow. ROP al- lows Turing-complete attacks by chaining together multiple Figure 1: PA uses a pointer authentication code (PAC) based gadgets, i.e., adversary-chosen sequences of pre-existing pro- on the pointer’s address, a modifier, and a key. gram instructions that together perform the desired operations. 1 prologue: ARM architectures use the link register (LR) to hold the cur- 2 paciasp ; signLR usingSP rent function’s return address. LR is automatically set by the 3 str LR,[SP] ; pushLR onto stack branch with link (bl) or branch with link to register (blr) 4 ... instructions that are used to implement regular and indirect 5 epilogue: 6 ldr LR,[SP] ; pop stack ontoLR function calls. Because LR is overwritten on call, non-leaf 7 retaa ; verifyLR and return functions must store the return address onto the stack. This opens up the possibility of ROP on ARM [30]. Listing 1: The -mbranch-protection feature in GCC and LLVM/Clang uses PA to sign () and verify ( ) the return address in LR. PA does not access memory directly, the LR 2.2 ARM Pointer Authentication value is stored () and loaded () conventionally. The ARMv8.3-A PA extension supports calculating and veri- fying pointer authentication codes (PACs) [4]. PA is at present 2.2.1 PA-based return address protection deployed in the Apple A12, A13, S4, and S5 systems-on-chip (SoCs) and is going to be available in all upcoming ARMv8.3- PA-based return address protection is implemented as part A and later SoCs. A pac instruction calculates a keyed tweak- of the -mbranch-protection feature of GCC and LLVM/- Clang.4 An authenticated return address is computed with able MAC, HK(AP,M), over the address AP of a pointer P using a 64-bit modifier M as the tweak. The resulting au- paciasp ( in Listing1) and verified with retaa ( ). These thentication token, referred to as a PAC, is embedded into instructions use the instruction key A and the value of stack the unused high-order bits of P. It can be verified using an pointer (SP) as the modifier. The PA-keys are protected by hardware; consequently an adversary has to resort to guessing aut instruction that recalculates HK(AP,M), and compares the result to P’s PAC. the correct PAC for a modified return address. Since the PAC is stored in unused bits of a pointer, its size The -mbranch-protection feature and other prior PA- is limited by the virtual address size (VA_SIZE in Figure1) based solutions are vulnerable to reuse attacks where an ad- and whether address tagging is enabled [4]. On a 64-bit ARM versary replaces a valid authenticated return address with machine running a default Linux kernel, VA_SIZE is 39, which another authenticated return address previously read from the leaves 16 bits for the PAC when excluding the reserved and process’ memory. For a reused PAC to pass verification, both address tag bits. PA provides five different keys; two for the original and replacement PAC must have been computed code pointers, two for data pointers, and one for generic use. using the same PA key and modifier. This applies to any PA Each key has a separate set of instructions, e.g., the autia scheme, not only authenticated return addresses. Using the SP and pacia instructions always operate on the instruction key value as a modifier reduces the set of interchangeable pointers, A, stored in the APIAKey_EL1 register. Access to the key but still allows reuse attacks when SP values coincide. Reuse registers and PA configuration registers can be restricted to a attacks can be mitigated, but not completely prevented, by higher exception level (EL). Linux v5.03 adds full support for further narrowing the scope of modifier values [35]. PA, such that the kernel (at EL1) manages user-space (EL0) keys and prevents EL0 from modifying them. The kernel 3 Adversary model and requirements generates new PA keys for a process on an exec system call. As currently specified, PA does not cause a fault on verifi- In this work, we consider a powerful adversary, A, with arbi- cation failure; instead, it strips the PAC from the pointer P and trary control of process memory but restricted by a W⊕X pol- flips one of the high-order bits such that P becomes invalid. icy that prevents modification of code pages. This adversary If the invalid pointer is used by an instruction that causes the model is consistent with prior work on run-time attacks [49]. pointer to be translated, such as load or instruction fetch, the We limit A to user space; thus A cannot read or modify kernel- memory management unit issues a memory translation fault. managed registers such as the PA keys.
3https://kernelnewbies.org/Linux_5.0#ARM_pointer_ 4https://gcc.gnu.org/gcc-9/changes.html and authentication https://reviews.llvm.org/D51429 We make the following assumptions about the system: the MAC key and the last authentication token authn must A1 AW⊕X policy protects code memory pages from modifi- be stored securely to ensure that previous auth tokens and cation by non-privileged processes. All major processor return addresses can be correctly verified when unwinding architectures, including ARMv8-A, support W⊕X. the call stack (R1). We use a tweakable MAC function HK to generate a b-bit authentication token auth : A2 Coarse-grained forward-edge control-flow integrity i (CFI) that restricts forward control-flow transfers to ( HK(reti,authi−1) if i > 0 a set of valid targets. Specifically, we assume that in- authi = direct function-calls always target the beginning of a HK(reti,0) if i = 0 function and that indirect jumps to arbitrary addresses is infeasible. This property is satisfied by several pre- authn is maintained in a register unmodifiable by A. Fig- existing software-only CFI solutions with reasonable ure3 shows how authentication tokens and return addresses overhead [1,18,31,37], as well as with negligible over- are stored on the call stack. On function calls, authi is re- head by using hardware-assisted mechanisms like ARM tained across the call to the callee, which calculates authi+1 and stores both authi and the corresponding return address PA [35], branch target indicators [4], or TrustZone- 0 0 M[5, 39]. In particular, a minimal PA scheme using reti+1 on its stack frame. On return, authi−1 and reti val- a constant (e.g., 0x0) modifier fulfills this assumption. ues are loaded from the stack and are verified by comparing H (auth0 ,ret0) to auth . If the results differ, then one or both This adversary model allows A to modify any pointer in K i−1 i i of the loaded values have been corrupted (R1). Otherwise, data memory pages. In particular, A can modify function re- they are valid—i.e., auth0 = auth and ret0 = ret —in turn addresses while they reside on the program call stack. i−1 i−1 i i which case auth is replaced with the verified auth in the A2 and A1 prevent A from tampering with ACS instrumen- i i−1 secure register before the function returns to ret . tation (Section 6.3). Our goal is to thwart A who modifies i For compactness, we can combine auth and ret , into an function return addresses in order to hijack the program con- i i authenticated return address, aret : trol flow. We define the following requirements: i
R1 Return address integrity: Detect if a function return ad- areti = authi k reti,where dress has been modified while in memory. ( HK(reti,areti−1) if i > 0 R2 Memory disclosure tolerance: Remain effective even authi = HK(reti,0) if i = 0 when A can read the entire process address space. R3 Compatibility: Be applicable to typical (standard- We call authi and the corresponding areti valid if authi = compliant) C code without source code modifications. HK(reti,areti−1) for some given areti−1. R4 Performance: Impose only minimal run-time perfor- mance and memory overhead, while meeting R1–R3. 4.1 Securing the authentication token
As in prior work on CFI, we do not consider non-control data The current authenticated return address aretn, is secured by attacks [12], such as data-oriented programming (DOP) [27]. keeping it exclusively in a CPU register which we call the chain register (CR). Note that reserving exclusive use of a register is also a requirement for current shadow stack imple- 4 Design: authenticated call stack mentation for the 64-bit ARM architecture [14] and has been proposed for shadow stacks on the x86 architecture [10]. In this section we present our general design for an authen- ACS protects the integrity of backward-edge control-flow ticated call stack (ACS). In Section5, we present our imple- transfers. Combined with coarse-grained forward-edge CFI mentation that efficiently realizes ACS using ARM PA. Our (Assumption A2), it ensures that: 1) immediately after func- key idea is to provide a modifier for the return address by tion return, the aretn in CR is valid, 2) at function entry the cryptographically binding it to all previous return addresses aretn−1 stored in CR is valid, and 3) CR is always used as or in the call stack. This makes the modifier statistically unique set to a valid aret. This ensures that token updates are done se- to a particular control-flow path, thus preventing reuse-type curely, and that the ACS instrumentation cannot be bypassed attacks and allowing precise verification of return addresses. or used to generate arbitrary authenticated return addresses. The return addresses reti,i ∈ [0,n] (where n is the depth of the call stack in terms of active function records) must be 4.2 Mitigating hash-collisions stored on the stack, where A can modify them by exploiting memory vulnerabilities. ACS protects these values by comput- Though aretn is protected by hardware, the size b of the au- ing a series of chained authentication tokens authi,i ∈ [0,n] thentication token auth can be limited by the implementation. that cryptographically bind the last authn to all return ad- Using a PAC as the token would typically limit it to 16 bits. dresses reti,i ∈ [0,n − 1] stored on the stack (Figure2). Only This is significant, as collisions can be found after A has auth0 = HK(ret0, 0) auth1 = HK(ret1, auth0) authn = HK(retn, authn-1)
ret0 ret1 retn
Figure 2: ACS is an chained MAC of tokens authi,i ∈ [0,n − 1] that are cryptographically bound to the corresponding return addresses, reti,i ∈ [0,n], and the last authn.
stack-frame0 can then attempt a new guess against another sibling pro- cess without resetting the key. In this scenario, 2b−1 guesses auth0 := HK(ret0, 0) ret0 on average are enough to obtain a modifier with respect to stack-frame1 auth1 := HK(ret1, auth0) which some combination of pointer and authentication token := HK(ret1, HK(ret0, 0)) auth0 is valid. Since this modifier becomes the next authenticated ret1 return address, the process can be repeated to use the injected auth := H (ret , auth ) stack-frame2 2 K 2 1 address. Because the two guesses can be done separately us- := H (ret , H (ret , auth )) K 2 K 1 0 ing a divide-and-conquer strategy, this requires on average := HK(ret2, HK(ret1, HK(ret0, 0))) 2b guesses to allow A to jump to an arbitrary address, rather than 22b that are needed when the guesses are independent. stack-framei authi := HK(reti, authi-1) Liljestrand et al. [35] recommend hardening pre-forking := HK(reti, HK(reti-1, authi-2)) and multi-threaded applications against guessing attacks by … authi-1 having the application restart all of its processes if the ret i number of PAC failures in child processes exceeds a pre- defined threshold. We recommend an alternative mitigation specific to ACS: "re-seeding" the auth calculation after a Figure 3: ACS stores return addresses and intermediate au- fork or thread creation. For example, calculating auth0 = thentication tokens, authi,i ∈ [0,n−1], on the stack. Only the HK(ret0,init) where init corresponds to the process or thread last token (authn) needs to be securely stored. ID. This solution is straightforward to apply to threads, as a return from the function starting the thread causes the thread seen, on average, approximately 1.253 · 2b/2 tokens [47, Sec- to exit. Crucially, re-seeding prevents a divide-and-conquer tion 1.4.2] (e.g., 321 tokens for b = 16). Despite this, we can guessing strategy and requires on average 22b guesses. There- still prevent A from recognizing collisions (R2), thus forcing fore, the ACS for the thread stacks can be made disjoint from A to guess—with a success probability 2−b—which authenti- the main ACS chain. However, forked processes may use cated return addresses yield a collision. The auth of any aret auth tokens in stack frames inherited from the parent process. stored on the stack is masked using a pseudo-random value If a child process never returns to inherited stack frames, re- derived from the previous aret value: seeding any new auth tokens beyond the point of the fork is sufficient. However, if the child process returns to inherited authi = HK(reti,areti−1) ⊕ HK(0,areti−1). stack frames, the ACS must be re-seeded starting from auth0 by rewriting any auth tokens in pre-existing stack frames; sim- The mask is exclusive-OR-ed with HK(reti,areti−1) after it is ilar to some stack canary re-randomization schemes [25, 43]. generated and before it is authenticated, thereby preventing A from identifying opportunities for pointer reuse. We discuss the security of masking in Section 6.2.1. 4.4 Irregular stack unwinding
4.3 Mitigating brute-force guessing The C standard includes the setjmp / longjmp programming interface, which can be used to add exception-like function- A brute force attack where A guesses an auth token succeeds ality to C. The longjmp C function executes a non-local with probability p for a b-bit auth after log(1−p) guesses, log(1−2−b) jump to a prior calling environment stored using the setjmp provided that a failed guess terminates the program and sub- function. At setjmp, callee-saved registers (whose values are sequent program runs use a new key to generate auth tokens. guaranteed to persist through function invocations), as well This assumption is similar to prior PA-based solutions [35] as the stack pointer SP, and the return address are stored in and is consistent with current PA behavior in Linux 5.0. the given jmp_buf buffer. Calling longjmp using an expired However, if pre-forked or multithreaded programs share buffer, i.e., after the corresponding setjmp caller has returned, the key, A can target a vulnerability in a sibling. Unless a results in undefined behavior (the implications of this are dis- failed authentication terminates the entire process tree, A cussed in Section 9.1). Because jmp_buf also stores the last authenticated token, ACS needs a mechanism to ensure its 1 prologue: integrity when using setjmp and longjmp. 2 str X28,[SP, #-32]! ; stack ← areti−1 While in memory, the integrity of jmp_buf cannot be guar- 3 stp FP,LR,[SP,#16] ; stack ← frame-record 4 pacia LR, X28 ; LR ← aret anteed. Nonetheless, the stored auth is bound to the corre- i i 5 mov X28,LR ; CR ← areti sponding authi−1 on the setjmp caller’s stack. This ensures 6 ... that longjmp always restores a valid ACS state. To limit 7 epilogue: 8 mov LR, X28 ; LR ← areti the set of values A can inject into jmp_buf, we replace the 0 9 ldr FP,[SP, #16] ; skip reti in frame-record setjmp return address retb in jmp_buf with aretb, defined as: 0 10 ldr X28[SP], #32 ; CR ← areti−1 from stack ∗ 11 autia LR, X28 ; LR ← (reti or reti ) aretb = (HK(retb,authi) k retb) ⊕ HK(SPb,authi), Listing 2: At function entry, PACStack stores areti−1 on the where SPb is the SP value stored in jmp_buf. When executing stack () and generates a new areti () which is retained in longjmp, aretb is recalculated based on the buffer values to CR (). Before return, areti−1 is loaded from the stack () verify that the stored authi was stored by a setjmp. A cannot and verified against areti (). Verification failure sets LR to generate the aretb value for an arbitrary authi, nor replace an invalid address ret∗ and causes a fault on return. aretb with a previously observed authi. But, since longjmp i explicitly allows jumping to prior states, ACS cannot ensure that the target is the intended one, i.e., A could substitute where autia will automatically handle verification errors by the correct jmp_buf with another. Shadow stacks share a ∗ setting LR to an unusable address reti . No additional checking similar limitation [17], and cannot guarantee that the intended ∗ is needed; executing a return to reti causes a address trans- state has been reached, only that the return address (and stack lation fault (Section 2.2). To maintain compatibility (R3), pointer) in that state is intact. PACStack does not modify the frame record () and instead stores areti−1 in a separate stack slot (). This allows, for 5 Implementation: PACStack instance, debuggers to backtrace the call-stack without knowl- edge of PACStack. PACStack never loads reti from the frame We present PACStack, an ACS realization using ARMv8.3- record; it always uses areti which is securely stored in CR. A PA. PACStack is based on LLVM 9.0 and integrated into the 64-bit ARM backend. PACStack modifies the 5.1 Securing the authentication token AArch64FrameLowering such that the function stores and loads aretn−1 during FrameSetup and FrameDestroy, re- PACStack uses the ARM general purpose register X28 as CR spectively. We also modify the AArch64RegisterInfo to for storing the last authentication token. X28 is a callee-saved ensure that the register holding aretn, chain register (CR), is register, and so, any function that uses it must also restore reserved for PACStack use. Our current implementation uses the old value before return. By using X28 as CR, PACStack a Intermediate Representation (IR) pass to mark all functions libraries or code can be transparently mixed with uninstru- for instrumentation, whereas the backend then performs in- mented code (R3). We discuss the security implications of strumentation based on the function attribute. mixing instrumented and uninstrumented code in Section 9.2. The current authenticated return address is securely stored in CR. Because the unprotected return address ret is never i 5.2 Mitigating hash collisions: PAC masking stored on the stack, A is limited to manipulating the earlier authenticated return addresses on stack, i.e., areti,i ∈ [0,n − To prevent A from identifying PAC collisions that can be 1]. An authenticated return address must therefore pass two reused to violate the integrity of the call stack, PACStack authentications before use: first when being restored from the masks all authentication tokens values before storing them on stack, and second, when being used as the target of a function the stack. A pseudo-random value is obtained by generating return. We discuss the security implications in Section6. a PAC for address 0x0, pacia(0,areti−1) (Listing3 , ). PACStack uses the pacia and autia instructions to effi- By using pacia we efficiently obtain a pseudo-random value ciently calculate and verify authenticated return addresses that can be directly applied to the authentication token part of (Listing2, and ). The result of pacia is areti which is aret using only an exclusive-or instruction (eor , ). stored in the link register (LR, ) and moved to CR (): Because this construction uses the same key to generate ( both authentication tokens and masks, A must not obtain pacia(LR = reti,CR = areti−1) if i > 0 LR ← areti = an aret for a ret = 0x0 and any existing aret . PACStack pacia(LR = ret ,CR = init) if i = 0 i i i−1 i will never generate such aret values, as the return address The corresponding verification ( and ) are defined as: never points to memory address zero. To prevent leaking the ( mask directly, it is cleared after use (, ). Consequently no reti if HK(reti,CR) = authi HK(0,x) value is visible to A nor is it possible to pre-compute LR ← autia(LR = areti,CR) = ∗ reti otherwise, without the confidential PA key. 1 prologue: 1 longjmp_wrapper: ; X0 = jmp_buf 0 2 str X28,[SP, #-32]! ; stack ← areti−1 2 ldr X28, [X0, #a] ; CR ← areti 0 3 stp FP,LR,[SP,#16] ; stack ← frame-record 3 ldr LR, [X0, #r] ; LR ← aretb 0 4 mov X15,XZR ; X15 ← 0 4 ldr X15, [X0, #s] ; X15 ← SPb unmasked 0 0 5 pacia LR, X28 ; LR ← areti 5 pacia X15, X28 ;; X15 ← pacia(SPb,areti ) 6 pacia X15, X28 ; X15 ← maski 6 eor X28, X28, X15 ; CR ← retb unmasked autia LR, X28 ;; 0 0 7 eor LR,LR, X15 ; LR ← maski ⊕ areti 7 LR ← autia(aretb,areti ) 8 mov X15,XZR ; X15 ← 0 8 str LR, [Xb, #r] ; replace LR in jmp_buf 9 mov X28,LR ; CR ← areti 9 b
6 Security evaluation 5.3 Irregular stack unwinding
PACStack binds jmp_buf buffers to the areti at the time of We address three questions in this section: setjmp call by replacing the setjmp return address retb with 1) Is PAC reuse a realistic concern in prior PA-based schemes? its authenticated counterpart aretb before setjmp stores it to 2) Is the ACS scheme cryptographically secure? the jmp_buf (Section 4.4). The libc implementation is not 3) Do ACS’s guarantees hold when instantiated as PACStack? modified; instead setjmp / longjmp calls are replaced with the wrapper functions in Listings4 and5. 4Listings4 and5 are illustrative, complete wrapper code is available at The setjmp_wrapper (Listing4) replaces the return ad- https://github.com/pacstack/pacstack-wrappers 5https://git.kernel.org/pub/scm/linux/kernel/git/ dress in LR with aretb and then executes setjmp, which stores it in the buffer. The longjmp_wrapper (Listing5) retrieves torvalds/linux.git/tree/arch/arm64/kernel/entry.S?h=v5.0 6https://git.kernel.org/pub/scm/linux/kernel/git/ aretb, areti, and the SP values from jmp_buf, verifies their val- torvalds/linux.git/tree/arch/arm64/include/asm/processor.h? ues and writes retb into jmp_buf before executing longjmp. h=v5.0 1 void A(){ stack_disclose();} This requires two returns: one from a ‘loader’ function void 2 B(){ to load A’s aretB into LR, and another from C to the return 3 char buff[SIZE]; address ret contained in aret . 4 stack_overflow(buff); B B 5 } In the analyses below, we treat the auth token HK(P,m) as a 6 void func(){ random oracle with respect to both the pointer P and modifier A(); // <------7 m. This means that if HK(P,m) has never been computed by 8 // ... reusable return addresses| a function call, HK(P,m) will match any value with probabil- 9 B(); // <------−b 0 0 10 } ity 2 , independently of any other value HK(P ,m ). In the analysis below we assume that programs that share the same Listing 6: The -mbranch-protection implementation (Sec- PA keys between multiple processes or threads employ the tion 2.2.1) computes the PAC for return addresses using the mitigation strategy against brute-force attacks described in SP value at function entry. Both invocations in func (Lines7 Section 4.3. This assumption and the design of ACS ensure and9) will thus use the same SP value as modifier. A can that there is no authentication oracle available: the only way reuse the signed address from Line7 to make the function to test whether an auth token is valid with respect to some invocation at Line9 return to Line8. address and modifier is to attempt to return using the address and token, triggering a crash if the token is incorrect. 6.1 Reuse attacks on PA The difficulty of achieving these goals therefore depends on whether A’s desired control-flow violation follows the call Reuse attack on PA-based schemes are possible when the graph of the program and whether auth tokens are masked. modifier is calculated with known or predictably repeating Violating control-flow integrity while still traversing the call values. Using the SP can mitigate reuse attacks (Section 2.2.1). graph is easier because this allows A to harvest auth tokens However, -mbranch-protection generates the PAC imme- and search for collisions; violations that do not follow the call diately on function entry, before modifying the SP value to graph are more difficult because they require that A make one allocate stack space. All functions called from within a code or more guesses, risking a crash. segment use the same modifier unless there are dynamic stack allocations. Moreover, because the stack is typically aligned 6.2.1 Violations that follow the call graph to 8 bytes, the SP value will often repeat. For example, a As can harvest authenticated return pointers when they are less than 1s test execution of a SPEC CPU 2017 bench- A written to the stack, the short auth tokens mean that in the mark (538.imagick_r) already shows multiple collisions, absence of masking an attacker can violate the integrity of the with 5349 distinct (LR,SP) pairs, but only 914 unique SP val- call stack by finding collisions in H (·,·). ues. Listing6 shows a minimal example where all called K In order to achieve goal AG-Load, must find two authen- functions will end up using the same modifier and thus have A ticated return addresses aret and aret , such that i) they are interchangeable signed return addresses. A B both returned to by a function C, ii) that C contains a call-site to the loader function with a corresponding return address 6.2 ACS security retC, and iii) such that H (ret ,aret ) = H (ret ,aret ) = auth . (1) A generic representation of an attack against ACS is shown in K C A K C B collision Figure4. Under normal operation, function C returns to A if Note that the collisions must be for different values in the called from A (Figure 4a); i.e., when called from A, the return second argument only, since that is the value in A’s control. address of C is an address retA in A. The goal of A (Figure 4b) Collisions that require different values for retC cannot be is to cause C to return to some other address retB. exploited because retC is in CR and cannot be modified by A. aret Since the authenticated return address A containing The auth tokens contained in aretA and aretB depend on retA is protected from A, in order to perform a backward-edge the path that A has taken through the call graph. A can obtain control-flow attack, A must achieve two goals successfully: as many auth tokens with retC as a pointer as there are distinct execution paths leading to C. The number of such paths will AG-Jump: Obtain an authenticated return address aretB, explode combinatorially as the complexity of the program valid with respect to some known modifier, which will increases, and cycles in the call graph—as occur in Figure4— validate successfully when C returns. make the number of paths essentially infinite, limited only by available stack space. AG-Load: Violate the integrity of the call stack such that Having found such a collision, A then arranges for function the LR register is loaded with aretB from AG-Jump rather C to be called, traversing the call graph in such a way that it is than the correct authenticated return address aretA. set up to return to A using aretA. Then, when the function C calls into the loader function, it will set LR to aretC. When the A B A B
AG-Jump C C Correct control flow Correct control flow AG-Load loader
(a) Normal control flow. (b) A’s desired control flow. Figure 4: Anatomy of a backward-edge control-flow attack against ACS. In order to force function C to return to B instead of its caller A, A substitutes their authenticated return address aretB when some function—the ‘loader’—returns to retC in function C (goal AG-Load). If aretB is valid with respect to some known modifier, then at the end of function C the program will return to the corresponding retB (goal AG-Jump). loader function returns to retC, it will attempt to load aretA Violation type No masking Masking −b from the stack. Instead, A substitutes aretB, which because of On-graph 1 2 −b −b (1) will validate correctly when returning to retC. Since aretB Off-graph to call-site 2 2 is a valid authenticated return address, C will successfully Off-graph to arbitrary address 2−2b 2−2b return to retB, thereby violating the integrity of the call stack. More concretely, after collecting q auth tokens, according Table 1: Maximum success probability of call-stack integrity to the birthday paradox [47, Section 1.4.2], the probability violations, with and without masking. that some pair collides is: 6.2.2 Violations that leave the call graph 2b! p (q) = 1 − We now consider A’s probability of success when attempting collision (2b − q)! · 2q·b to return to an address retB in a way that that does not follow This quickly approaches 1 as A collects more tokens, on the program’s call graph. (Summary in Table1.) B C average occurring after obtaining In this case, the path from to has not been tra- versed, and the instrumentation has never before computed r the auth token H (ret ,aret ). Therefore, succeeds at AG- π2b K C B A q = Load—i.e., HK(retC,aretB) = HK(retC,aretA)—with probabil- 2 −b ity P[AG-Load] = 2 , irrespective of whether the substituted tokens. With a 16-bit PAC, A will therefore obtain a collision aretB is a valid authenticated return address. On failure, which after harvesting 321 pointers on average. has probability 1 − 2−b, the process will crash. In order to successfully mount the above attack, A must A’s probability of then achieving goal AG-Jump depends find two colliding auth tokens and perform the substitution. on whether retB is the return address of a valid call-site. If it Without masking, A can read the auth token from the stack. is, then A can obtain a valid authenticated return pointer for A can then keep collecting auth tokens until they find two that location in the same way as in Section 6.2.1. If retB has that collide; since these are both valid pointers, A will always never been used as a return address, then no auth token has succeed once this occurs, thus ever been generated for that pointer and AG-Jump is achieved −b with probability at most P[AG-Jump] = 2 , independent of P[AG-Load|Collision] = 1. AG-Load. A can therefore succeed with probability 2−b when the With masking A cannot identify auth token collisions: return address is a valid call-site return address, or with prob- −2b aretA and aretB have different mask values HK(0,aretA) and ability of 2 when the return address is not. HK(0,aretB). Therefore it is impossible to identify a collision with a probability greater than by random selection. This 6.3 Run-time attack resistance of PACStack means that A will succeed in the attack above with a proba- −b bility of 2 . We give a detailed proof in AppendixA. PACStack must ensure the integrity of aretn and the confiden- In practice, this means that A can use this attack to traverse tiality of the masks. The former is achieved by storing aretn the program’s call graph, but cannot jump to an address that in CR, which is reserved for this purpose, not used by regular is not a valid return address for function C. code, and hence, inaccessible to A (Section 5.1). The latter is maintained as the mask is re-generated each time it is needed 1 ... ; A injects P at
505.mcf_r Table 3: Requests/second, standard deviation (σ) and perfor- 519.lbm_r mance overhead for the NGINX SSL TPS tests reported for 525.x264_r both PACStack and PACStack-nomask.
538.imagick_r (instead of measuring throughput) to ensure that the load on 544.nab_r the web server is CPU-bound, allowing us to estimate the 557.xz_r upper bound for PACStack’s impact on NGINX performance. 600.perlbench_s We conducted our tests on two separate Amazon EC2 A1 602.gcc_s instances connected via elastic network interfaces with up to 10 Gbps capacity. The web server (on an a1.metal instance, 605.mcf_s running NGINX 1.17.8 with OpenSSL 1.1.1d) and the client 619.lbm_s (on an a1.4xlarge instance) ran the 64-bit ARM version of 625.x264_s Ubuntu 18.04. We configured the server to use the ECDHE- PACStack 638.imagick_s RSA-AES256-GCM-SHA384 cipher with a 2,048-bit RSA PACStack-nomask 12 ShadowCallStack key for HTTPS. The client used wrk , a modern HTTP bench- 644.nab_s -mbranch-protection marking tool, to generate traffic. We configured wrk in the -mstack-protector-strong 657.xz_s same way as in a test on NGINX performance conducted by F5 Networks.13 We ran a total of 15 copies of wrk on the Figure 5: Relative performance overhead for SPEC CPU 2017 client machine for 3 minutes each. benchmarks as mean overhead over baseline. Error bars are We repeated the test with four and eight NGINX worker pro- 95% confidence intervals. cesses instrumented with PACStack and PACStack-nomask, SPECrate SPECspeed and compared the results with uninstrumented baseline perfor- mance. In both configurations we also instrumented NGINX’s PACStack 2.75% 3.28% PACStack-nomask 0.86% 1.56% dependencies (OpenSSL, pcre and zlib libraries). All bina- ShadowCallStack 0.85% 0.77% ries were compiled with -O2 optimizations. We summarize -mbranch-protection 0.43% 0.72% the results in Table3, showing a 4–7% overhead for PAC- -mstack-protector-strong 0.43% 0.25% Stack-nomask and 6–13% overhead for PACStack. These re- sults are consistent with the performance overheads measures Table 2: Geometric mean of measured overheads. for SPEC CPU 2017 (Section 7.1). tion calls. For instance, the 519.lbm_r benchmark involves computations related to fluid dynamics and consists of large 7.3 Compatibility testing using ConFIRM nested loops with few function calls. Consequently we see little effect on the performance of 519.lbm_r. ConFIRM is a set small micro-benchmarking suite designed Based on these results, we expect the overhead for both to test compatibility and relevance of CFI solutions [52]. The PACStack configurations to be a) comparable to ShadowCall- suite is designed to test various corner-cases—e.g., function Stack, and b) negligible on PA-capable hardware. pointers, setjmp/longjmp and exception handling—that often cause compatibility issues for CFI solutions. ConFIRM is 7.2 Real-world evaluation: NGINX designed for x86-based architectures and includes some tests that are exclusive to the Microsoft Windows operating system. We evaluated the efficacy of PACStack in a real-world setting Of the 18 64-bit Linux tests 11 compiled and worked on using a SSL/TLS transactions per second (SSL TPS) test on AArch64; these included virtual and indirect function calls, the NGINX11 open source web server software. SSL TPS setjmp/longjmp, calling conventions, tail calls and load-time measures a web server’s capacity to create new SSL/TLS dynamic linking. We ran these benchmarks on the FVP (to connections back to clients. Clients send a series of HTTPS guarantee functional equivalence to PA-capable hardware) requests, each on a new connection. The web server sends and confirmed that the tests passed with or without PACStack. a 0-byte response to each request. The connection is closed after the response is received. We chose the SSL TPS test 12https://github.com/wg/wrk (version of April 18, 2019) 13https://www.nginx.com/blog/nginx-plus-sizing-guide- 11https://www.nginx.com/ how-we-tested/ 8 Related Work Park et al. [42] present a micro-architectural shadow stack implementation using the branch predictor return address Control-flow hijacking have been known for more than two stack, a common hardware feature found in modern specula- decades [48]. Most current CFI solutions are stateless: they tive superscalar processor designs. The return address stack validate each control-flow transfer in isolation without dis- is typically a circular buffer; to avoid losing stored return tinguishing among different paths in the control-flow graph addresses when the maximum capacity is reached, Park et (CFG). Fully-precise static CFI [11] is the most restrictive al. modify the return address stack to spill a portion of its stateless policy possible without breaking the intended func- content to backup storage in main memory. A Merkle-tree tionality of the protected program. In fully-precise static CFI caching scheme is used to efficiently authenticate the backup the best possible policy for return instructions is to allow re- storage before it is read back to the return address stack. The turns within a function F to target any instruction that follows latency of spill/fill operations on backup memory is offset by a call to F. All stateless CFI schemes, including fully-precise the 100% hit rate for branch prediction since return addresses static CFI, are vulnerable to control-flow bending [11]. that exceed the return address stack capacity are retained. Stateful CFI can express policies that take previous control- The idea of using of MACs to protect the return address at flow transfers into account. HAFIX [19] is a hardware-assisted run-time was introduced in Cryptographic CFI (CCFI) [37] CFI scheme that confines function returns to active call sites. which uses MACs to protect return addresses and other Context-sensitive CFI [20, 28, 51] further ensures that each control-flow data (e.g., function pointers and C++ vtable point- control-flow transfer taken by the program is consistent with ers). CCFI’s return address protection is similar to PA-based a non-malicious trace. Despite its better precision, context- return address signing [45]; both bind the return address to sensitive CFI enforcement is considered impractical for real- the address of the function’s stack frame and thus provide world adoption [1]. Hardware-assisted branch recording fea- only coarse-grained resistance against pointer reuse [35]. In tures available in modern 64-bit Intel microprocessors can contrast to PACStack, these approaches cannot prevent reuse be used to enable context-sensitive CFI enforcement on com- attacks (See Section 6.1). Independently to our work, Li et modity hardware, but suffer from i) limited branch history al. [34] propose a chain structure to protect return addresses used to make CFI decisions, ii) over-approximation of the pro- but do not prevent the attacker from exploiting MAC colli- gram CFG, and iii) reliance on complex run-time monitoring. sions, and require custom hardware to realize their solution. HAFIX, on the other hand, requires changes to the processor. Program Counter Encoding [16, 22, 33, 41, 44] protects As dynamic schemes, PACStack and shadow call stacks [1, return addresses on the stack by encoding them with either 6, 13–15, 17, 18, 22–24, 29, 38, 39, 50] are not vulnerable to a register-resident secret key [33], a read-only key stored in control-flow bending. Stateless forward-edge CFI enforce- memory [16], the SP [44], or the address at which the return ment is often combined with a shadow stack to enforce the address itself is stored (a.k.a. the self-address)[41]. It is effi- integrity of return addresses stored on the call stack. In fact, cient, but relying on a secret key resident in user space makes the results by Carlini et al. [11] show that a shadow stack (or such encoding schemes susceptible to buffer over-reads, and equivalent mechanism) is essential for the security of CFI. SP or self-address encoding suffer the same drawbacks as However, traditional shadow stacks incur significant perfor- -msign-return-address [35, 45] (Section 2.2.1). mance overhead and lead to false positives for programming Other prominent defenses against control-flow attacks in- constructs that cause mismatches between calls and returns clude fine-grained code randomization [32], and code-pointer (C++ exceptions with stack unwinding, setjmp/longjmp). integrity (CPI) [31]. Code randomization makes it more dif- Recent designs improve performance by either leveraging a ficult for A to find suitable gadgets to exploit, but ineffec- parallel shadow stack [17], or using a dedicated register for tive if A knows the program memory layout. CPI protects shadow stack addressing [10]. But since the shadow stack in code pointers by storing them in a separate safe stack, which this schemes resides in the same address space as the target requires similar integrity guarantees as shadows stacks to application, it can be compromised if A knows its location. remain effective [21]. Roessler et al. propose a metadata- A typical solution for dealing with mismatches between calls tagged architecture to isolate stack-objects based on the stack- and returns is to pop return addresses off the shadow stack depth [46]. However, similar to the SP value (Section 6.2), the until a match is found, or the shadow stack is empty (e.g., stack-depth will repeat frequently during program execution. binary RAD [13]). This not only increases the complexity PACStack targets the ARM architecture, which has received and run-time of the shadow stack instrumentation placed in less attention compared to the x86 family of computer archi- the function epilogue, but also sacrifices precision, e.g., it al- tectures in terms of CFI research. MoCFI [18] is a software- lows A to redirect longjmp to any previously active call site. based CFI approach specifically targeting ARM application This can be avoided by storing and validating both the return processors used in smartphones. It uses a combination of a address and stack pointer [15, 40, 50]. So far, only hardware- shadow stack, static analysis and run-time heuristics to deter- assisted shadow stacks promise to achieve negligible overhead mine the set of valid targets for control-flow transfers, but suf- without security trade-offs (e.g., Intel CET [29]). fers from the same drawbacks that plague traditional shadow stack schemes. CFI CaRE [39] is a CFI solution targeting in mobile operating systems like Android, where multiple small, embedded ARM-based microcontrollers (MCUs). It stakeholders provide application binaries to consumer de- uses the ability to perform hardware-enforced isolated exe- vices. The deployment of PACStack, or any other run-time cution on ARMv8-M MCUs to isolate the shadow stack to protection mechanism, is likely to be driven by OEMs that a secure processor state. The ARMv8-M [5] architecture en- enable specific protection schemes for the operating system forces that calls to secure functions must target secure gate and system applications. However, OEMs are not in control instructions placed at the beginning of such functions. The of native code deployed as part of applications. It should ARMv8.5-A architecture introduces similar branch target be possible for one version of the shared libraries shipped indicators (BTI) [4] to ARM application processors. BTI with the operating system to remain interoperable with both constitutes one way to meet the PACStack pre-requisite of PACStack-protected, and unprotected apps. coarse-grained CFI (Section3). In Section 5.1 we explain how the use of callee-saved registers allows PACStack to remain interoperable with unpro- 9 Discussion tected code. Recall that because CR is a callee-saved register it will be restored upon return. However, PACStack cannot guar- 9.1 Support for software exceptions antee that CR remains unmodified during the execution of the unprotected code that could temporarily store its value on the The setjmp / longjmp interface has traditionally been used stack. To meet the security guarantees (Section6), PACStack to provide exception-like functionality in C. However, modern instrumentation must be applied to both the application and coding standards for C and C++ that aim to facilitate code any shared libraries. But partial protection, e.g. PACStack- safety, security, and reliability consider them harmful and protected shared libraries can significantly raise the bar for forbid their use, e.g., MISRA C:2004 [26, Rule 20.7] and JSF the attacker, as calls into protected functions can still benefit AV C++ [36, Rule 20]. Recall from Section 4.4 that calling from return address authentication. Common shared libraries longjmp with an expired jmp_buf is undefined behavior. For like libc are a popular source for gadgets for run-time at- PACStack, this means that although the aretb in jmp_buf is tacks because of their size and availability. Because functions tied to the corresponding SP and authi, its freshness cannot be in a PACStack-protected library validate the return address guaranteed. A can modify jmp_buf to contain the previously in returns from library functions, they effectively remove a used aretb and SPb, but must also modify the stack-frame at potentially large set of reusable gadgets from A’s disposal. SPb, such that it contains the prior areti. This allows a control- flow transfer to a previously valid setjmp return site and SP value. To prevent reuse of expired jmp_buf buffers, longjmp 10 Conclusion can be rewound step-by-step, i.e., conceptually performing returns until the correct stack-frame is reached. ACS achieves security on-par with hardware-assisted shadow We plan to extend PACStack support to LLVM stacks (Section6). With PACStack, we demonstrate how the libunwind14 – it does frame-by-frame unwinding of the call general-purpose security PA security mechanism can realize stack. By validating the ACS on each stack frame unwinding, our design, without requiring additional hardware support PACStack can ensure that a fresh and valid state is reached. or compromising security. Other general-purpose primitives As C++ exceptions also cause irregular stack unwinding like memory tagging and branch target indicators are being they pose a similar challenge. But C++ does finer-grained rolled out. Creative uses of such primitives hold the promise stack unwinding to correctly destroy objects in unwound of significantly improving software protection. stack frames. The LLVM libcxxabi library will, depend- libunwind ing on configuration, use for this purpose. With Acknowledgments PACStack support in libunwind, we will be able to secure both setjmp / longjmp and support C++ exception handling. This work was supported in part by NSERC (RGPIN-2020- 04744), Intel Collaborative Research Institute for Collabo- 9.2 Interoperability with unprotected code rative Autonomous & Resilient Systems (ICRI-CARS), and Google (ASPIRE program). We acknowledge the computa- Interoperability with unprotected (uninstrumented) code is tional resources provided by the Aalto Science-IT project. an important deployment consideration. On one hand, PAC- Stack-protected applications may need to interoperate with unprotected shared libraries. On the other, unprotected appli- References cations may need to interoperate with PACStack-protected shared libraries. The latter scenario is relevant for deployment [1] Martín Abadi et al. Control-flow integrity principles, 14https://github.com/llvm/llvm-project/tree/master/ implementations, and applications. ACM Trans. Inf. Syst. libunwind Secur., 13(1):4:1–4:40, November 2009. [2] ARM Ltd. Fast models version 11.4 reference manual. [15] Marc L. Corliss, E. Christopher Lewis, and Amir Roth. https://developer.arm.com/documentation/ Using DISE to protect return addresses from attack. 100964/1104-00/, 2018. ARM SIGARCH Comput. Archit. News, 33(1):65–72, 2005. [3] ARM Ltd. Developments in the Arm A- profile architecture: Armv8.6-A. https: [16] Crispin Cowan et al. PointGuard: Protecting pointers //community.arm.com/developer/ip-products/ from buffer overflow vulnerabilities. In Proc. USENIX processors/b/processors-ip-blog/posts/arm- Security ’03, pages 91–104, 2003. architecture-developments-armv8-6-a, 2019. [17] Thurston H.Y. Dang, Petros Maniatis, and David Wag- [4] ARM Ltd. ARM architecture reference manual ner. The performance cost of shadow stacks and stack (ARM DDI 0487F.c). https://developer.arm.com/ canaries. In Proc.ACM ASIA CCS ’15, pages 555–566, documentation/ddi0487/fc, 2020. 2015.
[5] ARM Ltd. Armv8-M architecture reference manual [18] Lucas Davi et al. MoCFI: A framework to mitigate (ARM DDI 0553B.l). https://developer.arm.com/ control-flow attacks on smartphones. In Proc. NDSS documentation/ddi0553/bl/, 2020. ’12, 2012.
[6] Sergei Arnautov and Christof Fetzer. ControlFreak: [19] Lucas Davi et al. HAFIX: Hardware-assisted flow in- Signature chaining to counter control flow attacks. In tegrity extension. In Proc. ACM/EDAC/IEEE DAC ’15, Proc. IEEE SRDS ’15 , pages 84–93, 2015. pages 74:1–74:6, 2015. [7] Roberto Avanzi. The QARMA block cipher family. [20] Ren Ding et al. Efficient protection of path-sensitive almost MDS matrices over rings with zero divisors, control security. In Proc. USENIX Security ’17, pages nearly symmetric even-mansour constructions with non- 131–148, 2017. involutory central rounds, and search heuristics for low- latency s-boxes. IACR Trans. Symmetric Cryptol., [21] Isaac Evans et al. Missing the point(er): On the effec- 2017(1):4–44, 2017. tiveness of code pointer integrity. In Proc. IEEE S&P ’15 [8] Brandon Azad. Google Project Zero: Examining , pages 781–796, 2015. https: pointer authentication on the iPhone XS. [22] Michael Frantzen and Michael Shuey. StackGhost: //googleprojectzero.blogspot.com/2019/02/ Hardware facilitated stack protection. In Proc. USENIX examining-pointer-authentication-on.html , Security ’01, pages 55–66, 2001. 2019. [23] Jonathon T. Giffin, Somesh Jha, and Barton P. Miller. [9] Erik Bosman and Herbert Bos. Framing signals - a Detecting manipulated remote call streams. In Proc. return to portable shellcode. In Proc. IEEE S&P ’14, USENIX Security ’02, pages 61–79, 2002. pages 243–258, 2014.
[10] Nathan Burow, Xingping Zhang, and Mathias Payer. [24] Jonathon T. Giffin, Somesh Jha, and Barton P. Miller. Proc. SoK: Shining light on shadow stacks. In Proc. IEEE Efficient context-sensitive intrusion detection. In NDSS ’04 S&P ’19, pages 985–999, 2019. , 2004.
[11] Nicolas Carlini et al. Control-flow bending: On the [25] William H. Hawkins, Jason D. Hiser, and Jack W. David- effectiveness of control-flow integrity. In Proc. USENIX son. Dynamic canary randomization for improved soft- Security ’15, pages 161–176, 2015. ware security. In Proc. ACM CISRC ’16, pages 9:1–9:7, 2016. [12] Shuo Chen et al. Non-control-data attacks are realistic threats. In Proc. USENIX Security ’05, pages 177–191, [26] HORIBA MIRA Ltd. Guidelines for the use of the C 2005. language in critical systems, 2004.
[13] Tzi-Cker Chiueh and Fu-Hau Hsu. RAD: A compile- [27] Hong Hu et al. Data-oriented programming: On the time solution to buffer overflow attacks. In Proc. IEEE expressiveness of non-control data attacks. In Proc. ICDCS ’01, pages 409–417, 2001. IEEE S&P ’16, pages 969–986, 2016.
[14] Clang 9.0 Documentation. ShadowCallStack. [28] Hong Hu et al. Enforcing unique code target property https://releases.llvm.org/9.0/tools/clang/ for control-flow integrity. In Proc. ACM CCS ’15, pages docs/ShadowCallStack.html, 2019. 1470–1486, 2018. [29] Intel Corporation. Control-flow Enforcement [44] Changwoo Pyo and Gyungho Lee. Encoding func- Technology specification, revision 3.0. https: tion pointers and memory arrangement checking against //software.intel.com/sites/default/files/ buffer overflow attack. In Proc. ICICS ’02, pages 25–36, managed/4d/2a/control-flow-enforcement- 2002. technology-preview.pdf, 2019. [45] Qualcomm. Pointer authentication on ARMv8.3. [30] Tim Kornau. Return Oriented Programming for https://www.qualcomm.com/media/documents/ the ARM Architecture. PhD thesis, Ruhr-Universität files/whitepaper-pointer-authentication-on- Bochum, 2009. armv8-3.pdf, 2017. [31] Volodymyr Kuznetsov et al. Code-pointer integrity. In [46] Nick Roessler and Andre DeHon. Protecting the stack Proc. USENIX OSDI ’14, pages 147–163, 2014. with metadata policies and tagged hardware. In Proc. [32] Per Larsen et al. SoK: Automated software diversity. In IEEE S&P ’18, pages 478–495, 2018. Proc. IEEE S&P ’14, pages 276–291, 2014. [47] Nigel P. Smart. Cryptography Made Simple. Springer [33] Gyungho Lee and Akhilesh Tyagi. Encoded program Publishing Company, 1st edition, 2015. counter: Self-protection from buffer overflow attacks. In Proc. CSREA ICIC ’00, pages 387–394, 2000. [48] Solar Designer. lpr LIBC RETURN exploit. http://insecure.org/sploits/linux.libc. [34] Jinfeng Li et al. Zipper stack: Shadow stacks without return.lpr.sploit.html, 1997. shadow. arXiv:1902.00888 [cs.CR], 2019.
[35] Hans Liljestrand et al. PAC it up: Towards pointer [49] László Szekeres et al. SoK: Eternal war in memory. In integrity using ARM pointer authentication. In Proc. Proc. IEEE S&P ’13, pages 48–62, 2013. USENIX Security ’19, pages 177–194, 2019. [50] Caroline Tice et al. Enforcing forward-edge control- [36] Lockheed Martin Corporation. Joint Strike Fighter Air flow integrity in GCC & LLVM. In Proc. USENIX Vehicle C++ Coding Standards (Revision C), 2005. Security ’14, pages 941–955, 2014.
[37] Ali Jose Mashtizadeh et al. CCFI: Cryptographically [51] Victor van der Veen et al. Practical Context-Sensitive enforced control flow integrity. In Proc. ACM CCS ’15, CFI. In Proc. ACM CCS ’15, pages 927–940, 2015. pages 941–951, 2015. [52] Xiaoyang Xu et al. CONFIRM: Evaluating compatibil- [38] Danny Nebenzahl, Mooly Sagiv, and Avishai Wool. ity and relevance of control-flow integrity protections Install-time vaccination of windows executables to de- for modern software. In Proc. USENIX Security ’19, fend against stack smashing attacks. IEEE Trans. De- pages 1805–1821, 2019. pendable Secur. Comput., 3(1):78–90, 2006.
[39] Thomas Nyman et al. CFI CaRE: Hardware-supported call and return enforcement for commercial microcon- A Security proofs trollers. In Proc. RAID ’17, pages 259–284. Springer In Section 6.2, we gave an informal analysis of the security of International Publishing, 2017. ACS; here we give a more detailed proof of security, and in [40] H. Ozdoganoglu et al. SmashGuard: A hardware solu- particular prove that authentication token masking prevents tion to prevent security attacks on the function return ad- A from obtaining exploitable authentication token collisions. dress. IEEE Trans. Comput., 55(10):1271–1285, 2006. The argument proceeds as follows: we suppose that A, after obtaining q authentication tokens, can find a pair of inputs [41] Seho Park, Yongsuk Lee, and Gyungho Lee. Program (x,y) and (x,y0) whose authentication tokens H (·,·) collide. ® K counter encoding for ARM architecture. Journal of This can be used to construct a distinguisher of the masks Information Security, 8:42–55, 2017. HK(0,·) from a random string. The structure of the authentica- [42] Yong-Joon Park and Gyungho Lee. Repairing return tion tags is such that this further reduces to a semantic security address stack for buffer overflow protection. In Proc. game for one-time pad encryption of the masks. Then, we ACM CF ’04, pages 335–342, 2004. show that any violation of the integrity of an ACS-protected call stack also yields values whose authentication tokens col- [43] Theofilos Petsios et al. DynaGuard: Armoring canary- lide as described above, allowing us to bound the probability based protections against brute-force attacks. In Proc. of an integrity violation. ACM ACSAC ’15, pages 351–360, 2015. We summarize our notation in Table4. A λ Games GPAC-Distinguish(1 ,H,q)
GACS Security game for ACS integrity. K ←$ {0,1}λ (Figure 11)
GPAC-Collision Security game for the identification of colliding // B is given values of their choice from either authentication tokens. (Figure6) // HK(·,·) or a random oracle RO(x,y) GPAC-Distinguish Security game for the distinguishability of HK(·,·) de f S0(x,y) = RO(x,y) from a random oracle. (Figure7) de f S1(x,y) = HK(x,y) G1,G2,G3 Semantic security games for the mask HK(0,·). $ (Figure8) c ← {0,1} Adversary interfaces for i ∈ {1,...,q} do (x,y) ← Aoracle-request() GACS Aoracle-request Get path through the call-graph for Aoracle-response (Sc(x,y)) which A wants the final authenticated return address pushed to the stack. endfor Aoracle-response Return a previously-requested authen- ticated return address. // A is challenged to determine whether it received // values from HK(·,·) or the random oracle. AACS-Violation Return to the challenger authenticated return values that can be used to vio- cˆ ← Adistinguish() late call stack integrity. if c 6= cˆ then return 1 GPAC-Collision Aoracle-request Get a value for which A wants a masked authentication token. endif return 0 Aoracle-response Return a previously-requested masked authentication token. Agen-collision Return to the challenger two authenti- Figure 7: Security game in which A attempts to distinguish cated return values with colliding au- HK(·,·) from a random oracle. thentication tokens.
GPAC-Distinguish Aoracle-request Get a value for which A wants an au- thentication tag. Theorem 1 (PAC-masking prevents collision-finding). Sup- pose that after q queries, an adversary can distin- Aoracle-response Return a previously-requested authen- A tication token. guish HK(·,·) from a random oracle with advantage no A λ Adistinguish Return to the challenger a single bit greater than AdvPAC-Distinguish(1 ,H,q), as given in Figure7. identifying whether the given tokens Then, assuming a key-length of λ for HK(·,·), and given ac- were from a random oracle or H (·,·). K cess to q masked authentication tokens, A can identify a G1,G2 Bdistinguish Identify the authentication token func- 0 tion used to generate masked authenti- pair of inputs (xˆ,yˆ) and (xˆ,yˆ ) whose corresponding un- cation tokens. masked authentication tokens collide with advantage at most A λ G3 Bdistinguish’ As for G1,G2, but with the inputs rep- 2AdvPAC-Distinguish(1 ,H,q). resented as strings, not functions.
A λ Table 4: Notation used in AppendixA. Proof. We begin with a collision-game GPAC-Collision(1 ,H,q), shown in Figure6 in which the adversary is given oracle
λ access to the authentication token generator and then asked GA (1 ,H,q) 0 0 PAC-Collision to provide values x,y,y such that HK(x,y) = HK(x,y ). $ 0 K ← {0,1}λ An adversary that selects (x,y,y ) at random from VA_SIZE VA_SIZE+b VA_SIZE+b //Give A q masked authentication tokens {0,1} × {0,1} × {0,1} , such that //of their choice. y 6= y0, will win with probability 2−b; A’s advantage is there- for i ∈ {1,...,q} do fore (x,y) ← Aoracle-request() h i Aoracle-response (HK(x,y) ⊕ HK(0,y)) A λ A λ −b AdvPAC-Collision(1 ,H,q) = P GPAC-Collision(1 ,H,q) = 1 −2 . endfor // A is challenged to provide inputs whose authentication tokens collide. 0 We will bound this advantage by reduction to a semantic se- (xˆ,yˆ,yˆ ) ← Agen-collision() 0 0 curity game for the masks. We consider the following games, if yˆ 6= yˆ ∧ HK(xˆ,yˆ) = HK(xˆ,yˆ ) then return 1 shown in Figure8, and described in Figure9. endif The first hop, from G1 to G2, is based on indistinguisha- return 0 bility and relaxation: we suppose that HK(·,·) can be distin- guished from a random oracle with probability no more than Figure 6: Security game for finding colliding PACs given 1 A λ 2 + AdvPAC-Distinguish(1 ,H,q), and that the adversary is not masked authentication tokens. limited in the number of queries that can be made to the HK(·,·) → random oracle random oracle → random string
B λ B λ B λ G1 (1 ,H,q) G2 (1 ,H,q) G3 (1 ,H,q)
$ λ b 2b+VA_SIZE K ← {0,1} P1...2VA_SIZE ← {0,...,2 − 1} de f de f $ b 2b+VA_SIZE S0(y) = RO(y) S0(y) = RO0(y) S0 ← {0,...,2 − 1} de f de f $ b 2b+VA_SIZE S1(y) = HK(0,y) S1(y) = RO1(0,y) S1 ← {0,...,2 − 1} de f de f T(x,y),x 6= 0,first q queries = HK(x,y) ⊕ HK(0,y) T(x,y),x 6= 0 = RO1(x,y) ⊕ RO1(0,y) T1...2VA_SIZE ← P1...2VA_SIZE ⊕ S1
//The adversary is given S0 and S1 and challenged to //The adversary is given S0 and S1 and challenged to //The adversary is given S0 and S1 and challenged to
//determine which is used to calculate T(·,·). //determine which is used to calculate T(·,·). //determine which is used to calculate T···. $ $ c ← {0,1} c ← {0,1} c ←$ {0,1} cˆ ← Bdistinguish (T,Sc,S1−c) cˆ ← Bdistinguish (T,Sc,S1−c) cˆ ← Bdistinguish’ (T,Sc,S1−c) if c = cˆ then if c = cˆ then if c = cˆ then return 1 return 1 return 1 endif endif endif return 0 return 0 return 0
Figure 8: Security games used in Theorem1.
masked authentication token oracle. Then,
B λ A λ P[G1 (1 ,H,q) = 1] ≤ P[G2 (1 ,H,q) = 1] A λ + AdvPAC-Distinguish(1 ,H,q). GB (1λ,H,q): obtains masked authentication 1 B The second hop, from G2 to G3, is a mere reformulation of G2 tokens HK(x,y) ⊕ HK(0,y) for up to q pairs such that random oracles are represented as strings, and that (x,y) of B’s choice, and must then distin- rather than allowing B to request arbitrarily many authenti- guish the masks HK(0,·) from a random ora- cation tokens from the challenger, we instead give B direct cle. access to the oracle, as represented by the sequence of strings
random oracle T1...2VA_SIZE . →
) The third game is a semantic security game for the one- · ,
· VA_SIZE ( time pad, where is given 2 encryptions of S1 and
K A
H B λ G2 (1 ,H,q): This is the same as the previous then asked to distinguish between S1 and a random string. The game, except that H (·,·) is replaced by a B λ K perfect secrecy of the one-time pad means that P[G1 (1 ) = random oracle and is not limited in their 1 B 1] = 2 and so number of queries. B must now distinguish between two random oracles, one of which 1 [GB (1λ) = 1] ≤ + AdvA (1λ,H,q). (2) is used in computing the authentication to- P 1 2 PAC-Distinguish kens, and one of which is independent of the A λ authentication tokens. Finally, we provide a reduction from GPAC-Collision(1 ,H,q) Reformulation B λ A λ to G1 (1 ). Suppose A can win GPAC-Collision(1 ,H,q) with A λ advantage AdvPAC-Collision(1 ,H,q). Then, we define an ad- B λ versary A for G B (1λ), shown in Figure 10. G3 (1 ,H,q): This is the semantic security game A 1 B λ 1 for repeated one-time-pad encryptions of a This adversary wins G1 (1 ) with probability at least 2 + 1 A λ random string. 2 AdvPAC-Collision(1 ,H,q), and so by (2)
Figure 9: The game-hops used in Figure8. A λ A λ AdvPAC-Collision(1 ,H,q) ≤ 2AdvPAC-Distinguish(1 ,H,q).
If the MAC HK(·,·) is a pseudo-random function family with A λ respect to K, then AdvPAC-Distinguish(1 ,H,q) is negligible, and A λ thus so is AdvPAC-Collision(1 ,H,q). A A λ Boracle-request() GACS(1 ,H,C,q)
$ λ return Aoracle-request() 1 : K ← {0,1} 2 : //Give A q tokens from call-graph traversals. A 3 : for i ∈ {1,...,q} do Boracle-response(x) 4 : p1...m+1 ← Aoracle-request() (x) Aoracle-response 5 : //Is the request for a real path through the call-graph?
6 : if ∃ j : p j → p j+1 ∈/ edges(C) then A 0 Bdistinguish(T,S,S ) 7 : return 0
0 8 : endif x,y,y ← Agen-collision(T) 9 : authm ← TK(pm,TK(pm−1,···) k pm−1) k pm if S(y) ⊕ S(y0) = T(x,y) ⊕ T(x,y0) then 10 : Aoracle-response(authm) return 1 11 : endfor else 12 : ptrjumper, ptrcorrect,authcorrect,tcorrect, return 0 13 : ptradv,authadv,tadv ← AACS-Violation() endif 14 : //The substituted masked authenticated return address must be different. 15 : if ptr = ptr ∧ auth = auth then A correct adv correct adv Figure 10: An adversary B for G1 used in our black-box 16 : return 0 reduction of GPAC-Collision to G1. Not shown is the variant 17 : endif A 0 A 0 Bdistinguish’(T,S,S ) that is identical to Bdistinguish(T,S,S ) ex- 18 : //Does the return pointer authenticate correctly with the adversary’s cept that T, S, and S0 are given in the form of strings. 19 : //new masked authenticated return address as the modifier? 20 : if HK(ptrjumper,authcorrect k ptrcorrect) With a bound on A’s probability of successfully obtain- 21 : 6= HK(ptrjumper,authadv k ptradv) then ing a PAC collision, we may now obtain a bound on their 22 : return 0 probability of violating the integrity of an ACS-protected call 23 : endif 24 : //Did the adversary provide a valid masked authenticated return address? stack. 25 : if authadv = HK(ptradv,tadv) Theorem 2 (Security of ACS). Consider a program whose 26 : return 1 call stack is protected by ACS, which has a call-graph C and b- 27 : endif 28 : return 0 bit masked authentication tokens TK(x,y) = HK(x,y)⊕HK(0,y). Then, an adversary with arbitrary control over memory can Figure 11: Security game for ACS with respect to a program violate backward-edge control-flow integrity with probability having call-graph C and authentication token function TK(·,·). h A λ i h A λ i P GACS(1 ,H,C,q) ≤ P GPAC-Collision(1 ,H,q) was already executing a signal handler, and thus the kernel −b A λ ≤ 2 + 2AdvPAC-Distinguish(1 ,H,q) already has a reference copy of asigretn−1 on record, it stores asigretn−1 in the new signal frame and overwrites the secure Proof. We begin with a security game for ACS, shown in copy with asigretn. On sigreturn the kernel attempts to val- Figure 11. idate the PC and CR values in the signal frame as though the Our goal is to provide a black-box reduction from reference value was asigret0. If successful it performs the A λ A λ GACS(1 ,H,C,q) to GPAC-Collision(1 ,H,q). signal return to sigretn and restores aretn to CR. Otherwise A From line 24 of Figure 11, winning GACS implies that A the kernel assumes a return to a nested signal handler, and has obtained colliding authentication tokens, and therefore 0 0 A retrieves sigretn and asigretn−1 from the signal frame, vali- can win GA with probability at least [GA ]. Sub- 0 0 0 PAC-Collision P ACS dates them by calculating asigretn = HK(sigretn,asigretn−1) stituting the bound from Theorem1, we obtain the bound and comparing the result against the stored asigretn refer- given. ence value. If successful the kernel replaces asigretn with asigretn−1 in the secure kernel store and performs the signal B Mitigation of sigreturn attacks return to sigretn. If the validation fails the kernel terminates the process. This prevents A from 1) overwriting CR, and A solution for precluding sigreturn attacks against PACStack 2) forging the PC values in signal frames. For general protec- would be to include the signal return value to the PACStack tion against sigreturn attacks corrupting any register stored in chain via the PC value stored on the signal frame: the signal frame, all register values could be included in the asigret calculation using the pacga instruction and validated ( HK(sigreti,asigreti−1) if i > 0 at the time of sigreturn. asigreti = HK(sigreti,aretn) if i = 0 Upon signal delivery, the kernel stores a copy of asigretn se- curely in kernel space as a reference value. If the process