Reasoning About a Machine with Local Capabilities

Skorstengaard, Lau; Devriese, Dominique; Birkedal, Lars

doi:10.1007/978-3-319-89884-1_17

Cited by 17 publications

(28 citation statements)

References 35 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…In most work on verified compartmentalization [14,58,85], communication between low-level compartments is done by jumping to a specified set of entry points; the model considered here is more structured and enforces the correct return discipline. Skorstengaard et al have also recently investigated a secure stack-based calling convention for a simple capability machine [71]; they plan to simplify their calling convention using a notion of linear return capability [70] that seems similar to the one used in our micro-policy from §4.5.…”

Section: Related Workmentioning

confidence: 99%

“…Compartmentalization offers a strong, practical defense against a range of devastating low-level attacks, such as control-flow hijacks exploiting buffer overflows and other vulnerabilities in C, C++, and other unsafe languages [18,33,81]. Widely deployed compartmentalization technologies include process-level privilege separation [18,33,47] (used in OpenSSH [67] and for sandboxing plugins and tabs in web browsers [69]), software fault isolation [74,79] (e.g., Google Native Client [84]), WebAssembly modules [34] in modern web browsers, and hardware enclaves (e.g., Intel SGX [38]); many more are on the drawing boards [14,20,71,81]. These mechanisms offer an attractive base for building more secure compilation chains that mitigate low-level attacks [30,33,44,65,[75][76][77].…”

Section: Introductionmentioning

confidence: 99%

See 1 more Smart Citation

When Good Components Go Bad

Abate

Amorim

Blanco

et al. 2018

Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security

View full text Add to dashboard Cite

We propose a new formal criterion for evaluating secure compilation schemes for unsafe languages, expressing end-to-end security guarantees for software components that may become compromised after encountering undefined behavior-for example, by accessing an array out of bounds. Our criterion is the first to model dynamic compromise in a system of mutually distrustful components with clearly specified privileges. It articulates how each component should be protected from all the others-in particular, from components that have encountered undefined behavior and become compromised. Each component receives secure compilation guarantees-in particular, its internal invariants are protected from compromised componentsup to the point when this component itself becomes compromised, after which we assume an attacker can take complete control and use this component's privileges to attack other components. More precisely, a secure compilation chain must ensure that a dynamically compromised component cannot break the safety properties of the system at the target level any more than an arbitrary attackercontrolled component (with the same interface and privileges, but without undefined behaviors) already could at the source level. To illustrate the model, we construct a secure compilation chain for a small unsafe language with buffers, procedures, and components, targeting a simple abstract machine with built-in compartmentalization. We give a careful proof (mostly machine-checked in Coq) that this compiler satisfies our secure compilation criterion. Finally, we show that the protection guarantees offered by the compartmentalized abstract machine can be achieved at the machine-code level using either software fault isolation or a tagbased reference monitor.

show abstract

Section: Related Workmentioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

When Good Components Go Bad

Abate

Amorim

Blanco

et al. 2018

Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security

View full text Add to dashboard Cite

show abstract

“…Practically, the only way accidental leaking can be avoided is by clearing unused registers and sweeping over this write-local memory to clear it entirely or at least erase local capabilities. For example, in a secure calling convention built on local capabilities, Skorstengaard et al [2018] have to clear the entire unused part of the stack before any invocation of adversarial code. This requirement is very costly in practice, and also hard to avoid, since the stack must be made write-local if we want to allow invoked code to spill registers or store local capabilities away during sub-invocations.…”

Section: Introductionmentioning

confidence: 99%

“…Although uninitialized capabilities are more generally useful, this paper focuses on how they redeem local capabilities as a revocation primitive. To this end, we formally establish the guarantees provided by local and uninitialized capabilities with a capability safety result based on the one by Skorstengaard et al [2018]. Capability safety is expressed as a universal contractÐor specificationÐ that holds for arbitrary assembly code.…”

Section: Introductionmentioning

confidence: 99%

“…To allow reasoning about the pattern of local capability revocation, we use a novel combination of Iris' invariants and saved predicates with more traditional Kripke world-indexing. We use this Kripke world-indexing with public/private transitions [Dreyer et al 2010;Skorstengaard et al 2018] and a new idea of what we call frozen regions to support typical patterns of (temporary) local capability revocation.…”

Section: Introductionmentioning

confidence: 99%

See 1 more Smart Citation

Efficient and provable local capability revocation using uninitialized capabilities

Georges

Guéneau

Strydonck

et al. 2021

Proc. ACM Program. Lang.

Self Cite

View full text Add to dashboard Cite

Capability machines are a special form of CPUs that offer fine-grained privilege separation using a form of authority-carrying values known as capabilities. The CHERI capability machine offers local capabilities, which could be used as a cheap but restricted form of capability revocation. Unfortunately, local capability revocation is unrealistic in practice because large amounts of stack memory need to be cleared as a security precaution. In this paper, we address this shortcoming by introducing uninitialized capabilities : a new form of capabilities that represent read/write authority to a block of memory without exposing the memory’s initial contents. We provide a mechanically verified program logic for reasoning about programs on a capability machine with the new feature and we formalize and prove capability safety in the form of a universal contract for untrusted code. We use uninitialized capabilities for making a previously-proposed secure calling convention efficient and prove its security using the program logic. Finally, we report on a proof-of-concept implementation of uninitialized capabilities on the CHERI capability machine.

show abstract

A Categorical Approach to Secure Compilation

Tsampas¹,

Nuyts²,

Devriese³

et al. 2020

Lecture Notes in Computer Science

Self Cite

View full text Add to dashboard Cite

We introduce a novel approach to secure compilation based on maps of distributive laws. We demonstrate through four examples that the coherence criterion for maps of distributive laws can potentially be a viable alternative for compiler security instead of full abstraction, which is the preservation and reflection of contextual equivalence. To that end, we also make use of the well-behavedness properties of distributive laws to construct a categorical argument for the contextual connotations of bisimilarity.

show abstract

Reasoning About a Machine with Local Capabilities

Cited by 17 publications

References 35 publications

When Good Components Go Bad

When Good Components Go Bad

Efficient and provable local capability revocation using uninitialized capabilities

A Categorical Approach to Secure Compilation

Contact Info

Product

Resources

About