Assessing the Impact of Interface Vulnerabilities in Compartmentalized Software

Abstract

Least-privilege separation decomposes applications into compartments limited to accessing only what they need. When compartmentalizing existing software, many approaches neglect securing the new inter-compartment interfaces, although what used to be a function call from/to a trusted component is now potentially a targeted attack from a malicious compartment. This results in an entire class of security bugs: Compartment Interface Vulnerabilities (CIVs).This paper provides an in-depth study of CIVs. We taxonomize these issues and show that they affect all known compartmentalization approaches. We propose ConfFuzz, an inmemory fuzzer specialized to detect CIVs at possible compartment boundaries. We apply ConfFuzz to a set of 25 popular applications and 36 possible compartment APIs, to uncover a wide data-set of 629 vulnerabilities. We systematically study these issues, and extract numerous insights on the prevalence of CIVs, their causes, impact, and the complexity to address them. We stress the critical importance of CIVs in compartmentalization approaches, demonstrating an attack to extract isolated keys in OpenSSL and uncovering a decade-old vulnerability in sudo. We show, among others, that not all interfaces are affected in the same way, that API size is uncorrelated with CIV prevalence, and that addressing interface vulnerabilities goes beyond writing simple checks. We conclude the paper with guidelines for CIV-aware compartment interface design, and appeal for more research towards systematic CIV detection and mitigation.

Software Compartmentalization Trade-Offs with Hardware Capabilities

“…It consists of marking compartment boundaries and shared data [22], e.g. with annotations, but also sometimes redesigning part of the software with security in mind [21]. If high, it can be a significant barrier to the adoption of compartmentalization, as it increases costs and development complexity [22].…”

“…Data sharing is however made at a coarser granularity, with the entire shared memory region accessible to both compartments at all times. This trades off security in two ways: 1) bounds are not tight to individual objects, thus not offering CHERI's spatial safety for shared objects; 2) even assuming no revocation in Approach 1, the number of objects effectively accessible by each compartment at any execution time will remain larger, resulting in more potential for compartment interface vulnerabilities [21]. In terms of scalability, this approach only scales to a small number of compartments: indeed one can create only a single overlapping region per pair of communicating compartment, hence a scenario with e.g.…”

“…When retrofitting compartmentalization to existing code bases, a key challenge is keeping refactoring costs low [4]. This is crucial not only for reducing the cost of deployment, but also to reduce the number of errors made during the compartmentalization, which can undermine its efficiency or security guarantees [21]. Work exploring compartmentalization with CHERI is so far limited to solutions with relatively high porting costs [11,32,41], that require a non-negligible reworking to the code corresponding to inter-compartment communications.…”

xOS

“…Another negative consequence of this proliferation of compartmentalization interfaces exposed to application code is that they are difficult to design and use correctly, which results in a new and growing set of security vulnerabilities [17]. We believe that abstracting away the isolation primitives exposed to the applications could help reduce the number of such vulnerabilities and simplify their mitigation by containing them in more controlled parts of the OS.…”