NoJITsu: Locking Down JavaScript Engines

Abstract

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%.

JIT Compiler Security through Low-Cost RISC-V Extension

“…Finally, data-only attacks are forcing the JIT compiler to generate malicious code by corrupting the JIT intermediate representation [5] or bytecodes [6], bypassing protections over JIT code and forcing the JIT compiler in generating the payload.…”

“…JITGuard [5] consists of an isolation of the compilation and execution processes of JIT code set up through hardware-based trusted execution environments (namely Intel SGX). NoJITsu [6] locks each critical object in the VM with keys and restricted permissions. Hardware-enforced memory isolation stands out in both cases as the solution that provides the less performance overhead and a way to refine isolation if needed in the future.…”

You shall not (by)pass!

“…Trusted code is then allowed to access both domains, whereas untrusted code can only access the untrusted domain. Furthermore, researchers have used PKU to harden JavaScript engines [59], reinforce other exploit mitigations [17,19,34,45], and provide software abstractions for isolation and sandboxing [58]. PKU can also be used to implement eXecute-Only Memory (XOM).…”