Polytope: Practical Memory Access Control for C++ Applications

Abstract

Designing and implementing secure software is inarguably more important than ever. However, despite years of research into privilege separating programs, it remains difficult to actually do so and such efforts can take years of labor-intensive engineering to reach fruition. At the same time, new intra-process isolation primitives make strong data isolation and privilege separation more attractive from a performance perspective. Yet, substituting intra-process security boundaries for time-tested process boundaries opens the door to subtle but devastating privilege leaks. In this work, we present Polytope, a language extension to C++ that aims to make efficient privilege separation accessible to a wider audience of developers. Polytope defines a policy language encoded as C++11 attributes that separate code and data into distinct program partitions. A modified Clang front-end embeds source-level policy as metadata nodes in the LLVM IR. An LLVM pass interprets embedded policy and instruments an IR with code to enforce the source-level policy using Intel MPK. A run-time support library manages partitions, protection keys, dynamic memory operations, and indirect call target privileges. An evaluation demonstrates that Polytope provides equivalent protection to prior systems with a low annotation burden and comparable performance overhead. Polytope also renders privilege leaks that contradict intended policy impossible to express.

Assessing the Impact of Interface Vulnerabilities in Compartmentalized Software

“…The compartmentalization framework enforces cross-compartment control-flow integrity: one compartment can only call explicit entry points exposed by other compartments. These assumptions fit the vast majority of modern frameworks [67], [60], [19], [53], [35], [25], [45], [5], [51], [30], [29], [1].…”

“…Recent years have seen the appearance of an increasingly large number of new isolation mechanisms [10], [4], [3], [65], [53], [45] that enable fine-grained compartmentalization. This resulted in compartmentalization works targeting finer and finer granularities, such as libraries [67], [60], [19], [42], [53], [35], [5], [51], [29], [2], modules [22], [2], [52], files [2], and even functions/blocks of code [16], [64], [57], [1]. In that context, major attention was dedicated to compartmentalizing existing code, since rewriting software from scratch to work in a compartmentalized manner is costly and complex [16].…”

“…In that context, major attention was dedicated to compartmentalizing existing code, since rewriting software from scratch to work in a compartmentalized manner is costly and complex [16]. With recent developments on compiler-based compartmentalization, frameworks offer to apply isolation at arbitrary interfaces for a low to non-existent porting cost [67], [5], [35], [1].…”

“…Even though interface-related vulnerabilities (denoted Compartment-Interface Vulnerabilities / CIVs in this paper) were previously identified to various extents in the literature [39], [8], [21], [61], almost all modern compartmentalization frameworks [67], [60], [19], [53], [35], [25], [45], [5], [51], [57], [30], [29], [1] neglect the problem of securing interfaces, and rather focus on transparent and lightweight spatial separation. Since CIVs are already problematic for interfaces hardened from the ground up (e.g., the system call API [28], [8]) with well-defined trust-models (kernel/user), their impact on safety is likely to be even greater when considering arbitrary interfaces and trust models that materialize when compartmentalizing existing software that was not designed with the assumption of hostile internal threats.…”

“…We apply ConfFuzz to a corpus of 39 compartmentalization scenarios, many of which previously proposed as use-cases of 12 existing research and industry frameworks. We uncover a wide data-set of 629 potential vulnerabilities 1 . We systematically study these issues, extracting numerous insights on the prevalence of CIVs, their causes, impact, and the complexity to address them.…”