PKRU-SAFE: Automatically Locking Down the Heap Between Safe and Unsafe Languages

Abstract

After more than twenty-five years of research, memory safety violations remain one of the major causes of security vulnerabilities in real-world software. Memory-safe languages, like Rust, have demonstrated that compiler technology can assist developers in writing efficient low-level code without the risk of memory corruption. However, many memory-safe languages still have to interface with unsafe code to some extent, which opens up the possibility for attackers to exploit memory-corruption vulnerabilities in the unsafe part of the system and subvert the safety guarantees provided by the memory-safe language.

In this paper, we present PKRU-SAFE, an automated method for enforcing the principle of least privilege on unsafe components in mixed-language environments. PKRU-SAFE ensures that unsafe (external) code cannot corrupt or otherwise abuse memory used exclusively by the safe-language components. Our approach is automated using traditional compiler infrastructure to limit memory accesses for developer-designated components efficiently. PKRU-SAFE does not require any modifications to the program's original data flows or execution model. It can be adopted by projects containing legacy code with minimal effort, requiring only a small number of changes to a project's build files and dependencies, and a few lines of annotations for each untrusted library.

We apply PKRU-SAFE to Servo, one of the largest Rust projects with approximately two million lines of Rust code (including dependencies) to automatically partition and protect the browser's heap from its JavaScript engine written in unsafe C/C++. Our detailed evaluation shows that PKRU-SAFE is able to thwart real-world exploits, often without measurable overhead, and with a mean overhead under 11.55% in our most pessimistic benchmark suite. As the method is language agnostic and major prototype components operate directly on LLVM IR, applying our techniques to other languages is straightforward.