Compiling Sandboxes: Formally Verified Software Fault Isolation

Besson, Frédéric; Blazy, Sandrine; Dang, Alexandre; Jensen, Thomas; Wilke, Pierre

doi:10.1007/978-3-030-17184-1_18

Cited by 7 publications

(3 citation statements)

References 34 publications

(40 reference statements)

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Other secure compilation work is targeted at closing down side-channels: for instance by preserving the secret independence guarantees of the source code [19], or making sure that the code erasing secrets is not simply optimized away by the unaware compilers [22,34,38,89]. Closer to our work is the work on building compartmentalizing compilation chains [5,23,50,98] for unsafe languages like C and C++. In particular, as mentioned above, Abate et al [5] have recently showed how RSP can be extended to express the security guarantees obtained by protecting mutually distrustful components against each other.…”

Section: Hypersafety Preservationmentioning

confidence: 99%

Journey Beyond Full Abstraction: Exploring Robust Property Preservation for Secure Compilation

Abate

Blanco

Garg

et al. 2019

2019 IEEE 32nd Computer Security Foundations Symposium (CSF)

View full text Add to dashboard Cite

Good programming languages provide helpful abstractions for writing secure code, but the security properties of the source language are generally not preserved when compiling a program and linking it with adversarial code in a low-level target language (e.g., a library or a legacy application). Linked target code that is compromised or malicious may, for instance, read and write the compiled program's data and code, jump to arbitrary memory locations, or smash the stack, blatantly violating any source-level abstraction. By contrast, a fully abstract compilation chain protects source-level abstractions all the way down, ensuring that linked adversarial target code cannot observe more about the compiled program than what some linked source code could about the source program. However, while research in this area has so far focused on preserving observational equivalence, as needed for achieving full abstraction, there is a much larger space of security properties one can choose to preserve against linked adversarial code. And the precise class of security properties one chooses crucially impacts not only the supported security goals and the strength of the attacker model, but also the kind of protections a secure compilation chain has to introduce.We are the first to thoroughly explore a large space of formal secure compilation criteria based on robust property preservation, i.e., the preservation of properties satisfied against arbitrary adversarial contexts. We study robustly preserving various classes of trace properties such as safety, of hyperproperties such as noninterference, and of relational hyperproperties such as trace equivalence. This leads to many new secure compilation criteria, some of which are easier to practically achieve and prove than full abstraction, and some of which provide strictly stronger security guarantees. For each of the studied criteria we propose an equivalent "property-free" characterization that clarifies which proof techniques apply. For relational properties and hyperproperties, which relate the behaviors of multiple programs, our formal definitions of the property classes themselves are novel. We order our criteria by their relative strength and show several collapses and separation results. Finally, we adapt existing proof techniques to show that even the strongest of our secure compilation criteria, the robust preservation of all relational hyperproperties, is achievable for a simple translation from a statically typed to a dynamically typed language.(∀C T . ∀t 1 , .., t k , ..(∀i.C T [P i ] t i ) ⇒ (t 1 , .., t k , ..) ∈ R)

show abstract

Section: Hypersafety Preservationmentioning

confidence: 99%

Journey Beyond Full Abstraction: Exploring Robust Property Preservation for Secure Compilation

Abate

Blanco

Garg

et al. 2019

2019 IEEE 32nd Computer Security Foundations Symposium (CSF)

View full text Add to dashboard Cite

show abstract

“…There is a large body of work that ensures the runtime checks are fast on different architectures, e.g., x86 [Ford and Cox 2008;McCamant and Morrisett 2006;Payer and Gross 2011;Yee et al 2009], x86-64 [Sehr et al 2010], SPARC ® [Adl-Tabatabai et al 1996], and ARM ® [Sehr et al 2010;Zhao et al 2011;Zhou et al 2014], as otherwise they incur unacceptable overheads on the code executing in the sandbox. Similarly, there is a considerable literature that establishes that the checks are correct [Besson et al 2019[Besson et al , 2018Kroll et al 2014;Morrisett et al 2012], as even a single missing check can let the attacker escape the sandbox.…”

Section: Introductionmentioning

confidence: 99%

Isolation without taxation: near-zero-cost transitions for WebAssembly and SFI

Kolosick

Narayan

Johnson

et al. 2022

Proc. ACM Program. Lang.

View full text Add to dashboard Cite

Software sandboxing or software-based fault isolation (SFI) is a lightweight approach to building secure systems out of untrusted components. Mozilla, for example, uses SFI to harden the Firefox browser by sandboxing third-party libraries, and companies like Fastly and Cloudflare use SFI to safely co-locate untrusted tenants on their edge clouds. While there have been significant efforts to optimize and verify SFI enforcement, context switching in SFI systems remains largely unexplored: almost all SFI systems use heavyweight transitions that are not only error-prone but incur significant performance overhead from saving, clearing, and restoring registers when context switching. We identify a set of zero-cost conditions that characterize when sandboxed code has sufficient structured to guarantee security via lightweight zero-cost transitions (simple function calls). We modify the Lucet Wasm compiler and its runtime to use zero-cost transitions, eliminating the undue performance tax on systems that rely on Lucet for sandboxing (e.g., we speed up image and font rendering in Firefox by up to 29.7% and 10% respectively). To remove the Lucet compiler and its correct implementation of the Wasm specification from the trusted computing base, we (1) develop a static binary verifier , VeriZero, which (in seconds) checks that binaries produced by Lucet satisfy our zero-cost conditions, and (2) prove the soundness of VeriZero by developing a logical relation that captures when a compiled Wasm function is semantically well-behaved with respect to our zero-cost conditions. Finally, we show that our model is useful beyond Wasm by describing a new, purpose-built SFI system, SegmentZero32, that uses x86 segmentation and LLVM with mostly off-the-shelf passes to enforce our zero-cost conditions; our prototype performs on-par with the state-of-the-art Native Client SFI system.

show abstract

“…There is also work on verification of sandboxing techniques like software-fault isolation [Besson et al 2019;Morrisett et al 2012], architectural meta-data tagging (micro-policies) [de Amorim et al 2015], and architectural memory capabilities [El-Korashy 2016]. However, these verification efforts are directed at meta-theoretic correctness properties of the sandboxing mechanisms themselves, e.g., that sandboxed code cannot directly access memory outside the sandbox.…”

Section: Introductionmentioning

confidence: 99%

The high-level benefits of low-level sandboxing

Sammler

Garg

Dreyer

et al. 2019

Proc. ACM Program. Lang.

View full text Add to dashboard Cite

Sandboxing is a common technique that allows low-level, untrusted components to safely interact with trusted code. However, previous work has only investigated the low-level memory isolation guarantees of sandboxing, leaving open the question of the end-to-end guarantees that sandboxing affords programmers. In this paper, we fill this gap by showing that sandboxing enables reasoning about the known concept of robust safety, i.e., safety of the trusted code even in the presence of arbitrary untrusted code. To do this, we first present an idealized operational semantics for a language that combines trusted code with untrusted code. Sandboxing is built into our semantics. Then, we prove that safety properties of the trusted code (as enforced through a rich type system) are upheld in the presence of arbitrary untrusted code, so long as all interactions with untrusted code occur at the łanyž type (a type inhabited by all values). Finally, to alleviate the burden of having to interact with untrusted code at only the łanyž type, we formalize and prove safe several wrappers, which automatically convert values between the łanyž type and much richer types. All our results are mechanized in the Coq proof assistant. One common engineering technique for ensuring secure interoperation between trusted and untrusted code is to physically sandbox the untrusted parts of an application at coarse granularity using hardware, kernel, or library support for isolation. Memory is partitioned into low and high compartments, and the hardware and kernel enforce that untrusted codeÐsandboxed in the low compartmentÐcannot directly access the memory in the high compartment (where trusted code operates) even if it can guess private memory addresses of the trusted code [Koning et al. 2017]. Additionally, untrusted code cannot directly access system calls. Examples of such techniques are software fault isolation by rewriting untrusted code [Yee et al. 2009], in-user-space sandboxing of untrusted libraries [Mozilla 2019; Lamowski et al. 2017; Google 2019; Vahldiek-Oberwagner et al. 2019], use of multiple kernel-backed address spaces within an application [Litton et al. 2016], and the use of modern features of CPUs like secure enclaves [McKeen et al. 2013; ARM Limited 2009].Although sandboxing is widely used, and prior work has shown formally that specific sandboxing techniques attain intrinsic properties like memory isolation, to the best of our knowledge there is no clear understanding of what end-to-end reasoning sandboxing affords programmers. Our goal in this paper is precisely to fill this gap: we show that sandboxing allows programmers to reason about the robust safety of trusted code. As explained above, robust safety is a well-studied concept, which means that the trusted code's safety properties hold even when co-executing with arbitrary untrusted code. In verification terms, sandboxing allows reasoning about the safety properties of trusted code without having to consider the behavior of untrusted code during verification.To formalize th...

show abstract

Compiling Sandboxes: Formally Verified Software Fault Isolation

Cited by 7 publications

References 34 publications

Journey Beyond Full Abstraction: Exploring Robust Property Preservation for Secure Compilation

Journey Beyond Full Abstraction: Exploring Robust Property Preservation for Secure Compilation

Isolation without taxation: near-zero-cost transitions for WebAssembly and SFI

The high-level benefits of low-level sandboxing

Contact Info

Product

Resources

About