NORAX: Enabling Execute-Only Memory for COTS Binaries on AArch64

Chen, Yaohui; Zhang, Dongli; Wang, Ruowen; Qiao, Rui; Azab, Ahmed M.; Lu, Long; Vijayakumar, Hayawardh; Shen, Wenbo

doi:10.1109/sp.2017.30

Cited by 28 publications

(23 citation statements)

References 32 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…JIT spraying attacks using one-and two-byte constants are, however, feasible in practice [7]. Similarly, there are several existing implementations of execute-only memory, but they only apply to statically generated code [8], [9], [15], [21], [23], [29], [43]. This leaves these implementations vulnerable to JIT-ROP attacks that only use gadgets found in the JIT code cache.…”

Section: A Overviewmentioning

confidence: 99%

NoJITsu: Locking Down JavaScript Engines

Park

Dhondt²,

Gens

et al. 2020

Proceedings 2020 Network and Distributed System Security Symposium

View full text Add to dashboard Cite

Data-only attacks against dynamic scripting environments have become common. Web browsers and other modern applications embed scripting engines to support interactive content. The scripting engines optimize performance via just-intime compilation. Since applications are increasingly hardened against code-reuse attacks, adversaries are looking to achieve code execution or elevate privileges by corrupting sensitive data like the intermediate representation of optimizing JIT compilers. This has inspired numerous defenses for just-in-time compilers. Our paper demonstrates that securing JIT compilation is not sufficient. First, we present a proof-of-concept data-only attack against a recent version of Mozilla's SpiderMonkey JIT in which the attacker only corrupts heap objects to successfully issue a system call from within bytecode execution at run time. Previous work assumed that bytecode execution is safe by construction since interpreters only allow a narrow set of benign instructions and bytecode is always checked for validity before execution. We show that this does not prevent malicious code execution in practice. Second, we design a novel defense, dubbed NOJITSU to protect complex, real-world scripting engines from data-only attacks against interpreted code. The key idea behind our defense is to enable fine-grained memory access control for individual memory regions based on their roles throughout the JavaScript lifecycle. For this we combine automated analysis, instrumentation, compartmentalization, and Intel's Memory-Protection Keys to secure SpiderMonkey against existing and newly synthesized attacks. We implement and thoroughly test our implementation using a number of real-world scenarios as well as standard benchmarks. We show that NOJITSU successfully thwarts codereuse as well as data-only attacks against any part of the scripting engine while offering a modest run-time overhead of only 5%.

show abstract

Section: A Overviewmentioning

confidence: 99%

NoJITsu: Locking Down JavaScript Engines

Park

Dhondt²,

Gens

et al. 2020

Proceedings 2020 Network and Distributed System Security Symposium

View full text Add to dashboard Cite

show abstract

“…More recent leakage-resistant schemes implement execute-only memory (XoM) for the code region, using software instrumentation such as selective paging [6], pointer masking [13], and range checking [71] or a variety of hardware-based isolation features on commodity architectures [55], such as Intel MPX [71], MPK [40,70], EPT [14,22,23,32], split TLB [33], or ARM's MMU/MPU builtins [19,59]. While these schemes prevent all reads from code memory pages, they are still vulnerable to advanced code-reuse attacks that only rely on code pointers leaked from data memory [73,91] and data-only attacks that do not even require code pointer corruption or control-flow hijacking at all [44].…”

Section: Background 21 Code-reuse Attacksmentioning

confidence: 99%

Speculative Probing

Göktaş

Razavi

Portokalidis

et al. 2020

Proceedings of the 2020 ACM SIGSAC Conference on Computer and Communications Security

View full text Add to dashboard Cite

To defeat ASLR or more advanced fine-grained and leakage-resistant code randomization schemes, modern software exploits rely on information disclosure to locate gadgets inside the victim's code. In the absence of such info-leak vulnerabilities, attackers can still hack blind and derandomize the address space by repeatedly probing the victim's memory while observing crash side effects, but doing so is only feasible for crash-resistant programs. However, high-value targets such as the Linux kernel are not crash-resistant. Moreover, the anomalously large number of crashes is often easily detectable. In this paper, we show that the Spectre era enables an attacker armed with a single memory corruption vulnerability to hack blind without triggering any crashes. Using speculative execution for crash suppression allows the elevation of basic memory write vulnerabilities into powerful speculative probing primitives that leak through microarchitectural side effects. Such primitives can repeatedly probe victim memory and break strong randomization schemes without crashes and bypass all deployed mitigations against Spectrelike attacks. The key idea behind speculative probing is to break Spectre mitigations using memory corruption and resurrect Spectrestyle disclosure primitives to mount practical blind software exploits. To showcase speculative probing, we target the Linux kernel, a crash-sensitive victim that has so far been out of reach of blind attacks, mount end-to-end exploits that compromise the system with just-in-time code reuse and data-only attacks from a single memory write vulnerability, and bypass strong Spectre and strong randomization defenses. Our results show that it is crucial to consider synergies between different (Spectre vs. code reuse) threat models to fully comprehend the attack surface of modern systems. CCS CONCEPTS • Security and privacy → Operating systems security.

show abstract

“…SECRET [158] provides XOM-equivalent protection to COTS binaries, using memory segmentation on x86 and information hiding on x86-64, while NORAX [27] leverages a combination of MMU permission bits to retrofit XOM to ARM binaries. In contrast, kR ∧ X enforces XOM on architectures that lack native support for marking memory pages as execute-only and employs strong memory isolation mechanisms (kR ∧ X-{SFI, MPX, SEG}), avoiding the use of information hiding to guard against direct JIT-ROP attacks, as this strategy has been shown to be ineffective in the kernel setting [70,74,78].…”

Section: Related Workmentioning

confidence: 99%

“…As a response to JIT-ROP attacks in user applications, execute-only memory prevents the (onthe-fly) discovery of gadgets by blocking read access to executable pages [27]. Nevertheless, given that widely used CPU architectures such as the x86 do not provide native support for enforcing execute-only permissions, such memory protection(s) can be achieved by relying on page table manipulation [9], TLB desynchronization [63], hardware virtualization [40,62], or techniques inspired by software-fault isolation (SFI) [86].…”

Section: Introductionmentioning

confidence: 99%

“…However, in kernel exploitation, a local (unprivileged) adversary, armed with an arbitrary (kernel-level) memory disclosure vulnerability [84,99] has increased flexibility in mounting a JIT-ROP attack on a diversified kernel [64], as any user program may attack the OS. Therefore, kernel JIT-ROP attacks are not only easier to mount but are also facilitated by the abundance of memory disclosure vulnerabilities in kernel code [88,100,102,108].As a response to JIT-ROP attacks in user applications, execute-only memory prevents the (onthe-fly) discovery of gadgets by blocking read access to executable pages [27]. Nevertheless, given that widely used CPU architectures such as the x86 do not provide native support for enforcing execute-only permissions, such memory protection(s) can be achieved by relying on page table manipulation [9], TLB desynchronization [63], hardware virtualization [40,62], or techniques inspired by software-fault isolation (SFI) [86].…”

mentioning

confidence: 99%

See 1 more Smart Citation

Untitled

2019

TOPS

View full text Add to dashboard Cite

The abundance of memory corruption and disclosure vulnerabilities in kernel code necessitates the deployment of hardening techniques to prevent privilege escalation attacks. As stricter memory isolation mechanisms between the kernel and user space become commonplace, attackers increasingly rely on code reuse techniques to exploit kernel vulnerabilities. Contrary to similar attacks in more restrictive settings, as in web browsers, in kernel exploitation, non-privileged local adversaries have great flexibility in abusing memory disclosure vulnerabilities to dynamically discover, or infer, the location of code snippets in order to construct code-reuse payloads. Recent studies have shown that the coupling of code diversification with the enforcement of a "read XOR execute" (R ∧ X) memory safety policy is an effective defense against the exploitation of userland software, but so far this approach has not been applied for the protection of the kernel itself.In this article, we fill this gap by presenting kR ∧ X: a kernel-hardening scheme based on execute-only memory and code diversification. We study a previously unexplored point in the design space, where a hypervisor or a super-privileged component is not required. Implemented mostly as a set of GCC plugins, kR ∧ X is readily applicable to x86 Linux kernels (both 32b and 64b) and can benefit from hardware support (segmentation on x86, MPX on x86-64) to optimize performance. In full protection mode, kR ∧ X incurs a low runtime overhead of 4.04%, which drops to 2.32% when MPX is available, and 1.32% when memory segmentation is in use. 5:2M. Pomonis et al. INTRODUCTIONThe deployment of standard kernel-hardening schemes, such as address space layout randomization (KASLR) [50] and non-executable memory [91], has prompted a shift from legacy code injection (in kernel space) to return-to-user (ret2usr) attacks [80]. Due to the weak separation between kernel and user space-as a result of the kernel being mapped inside the (upper part of the) address space of every user process for performance reasons-in ret2usr attacks, the kernel control/dataflow is hijacked and redirected to code/data residing in user space, effectively bypassing KASLR and (kernel-space) W ∧ X. Fortunately, however, recent software [38,69,80,116] and hardware [35,77] kernel protection mechanisms mitigate ret2usr threats by enforcing a more stringent address space separation. Alas, mirroring the co-evolution of attacks and defenses in user space, kernel exploits have started to rely on code-reuse techniques, such as return-oriented programming (ROP) [134,144]; old ret2usr exploits [14] are converted to use ROP payloads instead of shellcode [18], while modern jailbreak and privilege escalation exploits rely solely on code reuse [2,129,152].At the same time, the security community started developing protections against code-reuse attacks: control-flow integrity (CFI) [7] and code-diversification [44,72,87,112,149] schemes have been applied both in the user and kernel settings [42,58,64,94]. Unfortunately, the...

show abstract

NORAX: Enabling Execute-Only Memory for COTS Binaries on AArch64

Cited by 28 publications

References 32 publications

NoJITsu: Locking Down JavaScript Engines

NoJITsu: Locking Down JavaScript Engines

Speculative Probing

Untitled

Contact Info

Product

Resources

About