Results 1 - 10
of
12
Shielding applications from an untrusted cloud with haven.
- In OSDI,
, 2014
"... Abstract Today's cloud computing infrastructure requires substantial trust. Cloud users rely on both the provider's staff and its globally-distributed software/hardware platform not to expose any of their private data. We introduce the notion of shielded execution, which protects the conf ..."
Abstract
-
Cited by 14 (3 self)
- Add to MetaCart
(Show Context)
Abstract Today's cloud computing infrastructure requires substantial trust. Cloud users rely on both the provider's staff and its globally-distributed software/hardware platform not to expose any of their private data. We introduce the notion of shielded execution, which protects the confidentiality and integrity of a program and its data from the platform on which it runs (i.e., the cloud operator's OS, VM and firmware). Our prototype, Haven, is the first system to achieve shielded execution of unmodified legacy applications, including SQL Server and Apache, on a commodity OS (Windows) and commodity hardware. Haven leverages the hardware protection of Intel SGX to defend against privileged code and physical attacks such as memory probes, but also addresses the dual challenges of executing unmodified legacy binaries and protecting them from a malicious host. This work motivated recent changes in the SGX specification.
KCoFI: Complete control-flow integrity for commodity operating system kernels
- IEEE S&P
, 2014
"... We present a new system, KCoFI, that is the first we know of to provide complete Control-Flow Integrity protection for commodity operating systems without using heavyweight complete memory safety. Unlike previous systems, KCoFI protects commodity operating systems from classical control-flow hijack ..."
Abstract
-
Cited by 14 (1 self)
- Add to MetaCart
(Show Context)
We present a new system, KCoFI, that is the first we know of to provide complete Control-Flow Integrity protection for commodity operating systems without using heavyweight complete memory safety. Unlike previous systems, KCoFI protects commodity operating systems from classical control-flow hijack attacks, return-to-user attacks, and code segment modification attacks. We formally verify a subset of KCoFI’s design by modeling several features in small-step semantics and providing a partial proof that the semantics maintain control-flow integrity. The model and proof account for oper-ations such as page table management, trap handlers, context switching, and signal delivery. Our evaluation shows that KCoFI prevents all the gadgets found by an open-source Return Oriented Programming (ROP) gadget-finding tool in the FreeBSD kernel from being used; it also reduces the number of indirect control-flow targets by 98.18%. Our evaluation also shows that the performance impact of KCoFI on web server bandwidth is negligible while file transfer bandwidth using OpenSSH is reduced by an average of 13%, and at worst 27%, across a wide range of file sizes. PostMark, an extremely file-system intensive benchmark, shows 2x overhead. Where comparable numbers are available, the overheads of KCoFI are far lower than heavyweight memory-safety techniques. I.
Controlled-Channel Attacks: Deterministic SideChannels for Untrusted Operating Systems.
, 2015
"... Abstract-The presence of large numbers of security vulnerabilities in popular feature-rich commodity operating systems has inspired a long line of work on excluding these operating systems from the trusted computing base of applications, while retaining many of their benefits. Legacy applications c ..."
Abstract
-
Cited by 9 (0 self)
- Add to MetaCart
(Show Context)
Abstract-The presence of large numbers of security vulnerabilities in popular feature-rich commodity operating systems has inspired a long line of work on excluding these operating systems from the trusted computing base of applications, while retaining many of their benefits. Legacy applications continue to run on the untrusted operating system, while a small hypervisor or trusted hardware prevents the operating system from accessing the applications' memory. In this paper, we introduce controlled-channel attacks, a new type of side-channel attack that allows an untrusted operating system to extract large amounts of sensitive information from protected applications on systems like Overshadow, InkTag or Haven. We implement the attacks on Haven and InkTag and demonstrate their power by extracting complete text documents and outlines of JPEG images from widely deployed application libraries. Given these attacks, it is unclear if Overshadow's vision of protecting unmodified legacy applications from legacy operating systems running on off-the-shelf hardware is still tenable.
VC3: Trustworthy data analytics in the cloud using SGX.
- In IEEE Symposium on Security and Privacy,
, 2015
"... Abstract-We present VC3, the first system that allows users to run distributed MapReduce computations in the cloud while keeping their code and data secret, and ensuring the correctness and completeness of their results. VC3 runs on unmodified Hadoop, but crucially keeps Hadoop, the operating syste ..."
Abstract
-
Cited by 4 (2 self)
- Add to MetaCart
(Show Context)
Abstract-We present VC3, the first system that allows users to run distributed MapReduce computations in the cloud while keeping their code and data secret, and ensuring the correctness and completeness of their results. VC3 runs on unmodified Hadoop, but crucially keeps Hadoop, the operating system and the hypervisor out of the TCB; thus, confidentiality and integrity are preserved even if these large components are compromised. VC3 relies on SGX processors to isolate memory regions on individual computers, and to deploy new protocols that secure distributed MapReduce computations. VC3 optionally enforces region self-integrity invariants for all MapReduce code running within isolated regions, to prevent attacks due to unsafe memory reads and writes. Experimental results on common benchmarks show that VC3 performs well compared with unprotected Hadoop: VC3's average runtime overhead is negligible for its base security guarantees, 4.5% with write integrity and 8% with read/write integrity.
Nested Kernel: An Operating System Architecture for Intra-Kernel Privilege Separation
"... Monolithic operating system designs undermine the security of computing systems by allowing single exploits anywhere in the kernel to enjoy full supervisor privilege. The nested kernel operating system architecture addresses this problem by “nesting ” a small isolated kernel within a traditional mon ..."
Abstract
-
Cited by 1 (0 self)
- Add to MetaCart
Monolithic operating system designs undermine the security of computing systems by allowing single exploits anywhere in the kernel to enjoy full supervisor privilege. The nested kernel operating system architecture addresses this problem by “nesting ” a small isolated kernel within a traditional monolithic kernel. The “nested kernel ” interposes on all updates to virtual memory translations to assert protections on physical memory, thus significantly reducing the trusted computing base for memory access control enforcement. We incorporated the nested kernel architecture into FreeBSD on x86-64 hardware while allowing the entire operating system, including untrusted components, to operate at the highest hardware privilege level by write-protecting MMU translations and de-privileging the untrusted part of the kernel. Our implementation inherently enforces kernel code integrity while still allowing dynamically loaded kernel modules, thus defending against code injection attacks. We also demonstrate that the nested kernel architecture allows kernel developers to isolate memory in ways not possible in monolithic kernels by introducing write-mediation and write-logging services to protect critical system data struc-tures. Performance of the nested kernel prototype shows modest overheads: < 1 % average for Apache and 2.7 % for kernel compile. Overall, our results and experience show that the nested kernel design can be retrofitted to existing monolithic kernels, providing important security benefits.
Guarded Modules: Adaptively Extending the VMM’s Privileges Into the Guest
"... Open access to the Proceedings of the ..."
(Show Context)
A Design and Verification Methodology for Secure Isolated Regions
"... Abstract Hardware support for isolated execution (such as Intel SGX) enables development of applications that keep their code and data confidential even while running on a hostile or compromised host. However, automatically verifying that such applications satisfy confidentiality remains challengin ..."
Abstract
- Add to MetaCart
(Show Context)
Abstract Hardware support for isolated execution (such as Intel SGX) enables development of applications that keep their code and data confidential even while running on a hostile or compromised host. However, automatically verifying that such applications satisfy confidentiality remains challenging. We present a methodology for designing such applications in a way that enables certifying their confidentiality. Our methodology consists of forcing the application to communicate with the external world through a narrow interface, compiling it with runtime checks that aid verification, and linking it with a small runtime library that implements the interface. The runtime library includes core services such as secure communication channels and memory management. We formalize this restriction on the application as Information Release Confinement (IRC), and we show that it allows us to decompose the task of proving confidentiality into (a) one-time, human-assisted functional verification of the runtime to ensure that it does not leak secrets, (b) automatic verification of the application's machine code to ensure that it satisfies IRC and does not directly read or corrupt the runtime's internal state. We present /CONFIDENTIAL: a verifier for IRC that is modular, automatic, and keeps our compiler out of the trusted computing base. Our evaluation suggests that the methodology scales to real-world applications.
The Case for Less Predictable Operating System Behavior
"... "No one is so brave that he is not disturbed by something unexpected." Julius Caesar The operating system is increasingly regarded as untrustworthy. Applications, hardware, and hypervisors are erecting defenses to insulate themselves from the operating system. This paper explores the pote ..."
Abstract
- Add to MetaCart
"No one is so brave that he is not disturbed by something unexpected." Julius Caesar The operating system is increasingly regarded as untrustworthy. Applications, hardware, and hypervisors are erecting defenses to insulate themselves from the operating system. This paper explores the potential benefits if operating systems simply embraced these lowered expectations and deliberately varied API behavior. We argue that, even for trusted or benign applications, diversity roughly within the specification can improve resilience to attack and improve robustness. Malicious software tends to be brittle; a preliminary case study indicates that, for software of questionable origin, a somewhat hostile operating system may do more good than harm for system security. This paper describes the architecture of Chameleon, an ongoing project to implement spectrumbehavior as an operating system feature.
Iso-X: A Flexible Architecture for Hardware-Managed Isolated Execution
"... Abstract—We consider the problem of how to provide an execution environment where the application’s secrets are safe even in the presence of malicious system software layers. We propose Iso-X — a flexible, fine-grained hardware-supported framework that provides isolation for security-critical pieces ..."
Abstract
- Add to MetaCart
(Show Context)
Abstract—We consider the problem of how to provide an execution environment where the application’s secrets are safe even in the presence of malicious system software layers. We propose Iso-X — a flexible, fine-grained hardware-supported framework that provides isolation for security-critical pieces of an application such that they can execute securely even in the presence of untrusted system software. Isolation in Iso-X is achieved by creating and dynamically managing compartments to host critical fragments of code and associated data. Iso-X provides fine-grained isolation at the memory-page level, flexible allocation of memory, and a low-complexity, hardware-only trusted computing base. Iso-X requires minimal additional hardware, a small number of new ISA instructions to manage compartments, and minimal changes to the operating system which need not be in the trusted computing base. The run-time performance overhead of Iso-X is negligible and even the over-head of creating and destroying compartments is modest. Iso-X offers higher memory flexibility than the recently proposed SGX design from Intel, allowing both fluid partitioning of the available memory space and dynamic growth of compartments. An FPGA implementation of Iso-X runtime mechanisms shows a negligible impact on the processor cycle time. Keywords-hardware security; isolated execution; I.
Iso-X: A Flexible Architecture for Hardware-Managed Isolated Execution
"... Abstract—We consider the problem of how to provide an execution environment where the application’s secrets are safe even in the presence of malicious system software layers. We propose Iso-X: a flexible, fine-grained hardware-supported framework that provides isolation for security-critical pieces ..."
Abstract
- Add to MetaCart
(Show Context)
Abstract—We consider the problem of how to provide an execution environment where the application’s secrets are safe even in the presence of malicious system software layers. We propose Iso-X: a flexible, fine-grained hardware-supported framework that provides isolation for security-critical pieces of an application such that they can execute securely even in the presence of untrusted system software. Isolation is achieved by creating and dynamically managing execution compartments to host critical fragments of code and associated data. Iso-X provides fine-grained isolation at the memory-page level, flexible allocation of memory, and a low-complexity, hardware-only trusted computing base. Iso-X requires minimal additional hardware, a small number of new ISA instructions to manage compartments, and minimal changes to the operating system which need not be in the trusted computing base. The run-time performance overhead of Iso-X is negligible and even the overhead of creating and destroying compartments is modest. Iso-X offers significantly higher memory flexibility than the recently proposed SGX design from Intel, allowing both fluid partitioning of the available memory space and dynamic growth of compartments. An FPGA implementation of Iso-X runtime mechanisms shows a negligible impact on the processor cycle time. Keywords-security; isolated execution; I.