Raoul Strackx

Breaking the memory secrecy assumption

Many countermeasures exist that attempt to protect against buffer overflow attacks on applications written in C and C++. The most widely deployed countermeasures rely on artificially introducing randomness in the memory image of the application. StackGuard and similar systems, for instance, will insert a random value before the return address on the stack, and Address Space Layout Randomization (ASLR) will make the location of stack and/or heap less predictable for an attacker. A critical assumption in these probabilistic countermeasures is that attackers cannot read the contents of memory. In this paper we show that this assumption is not always justified. We identify a new class of vulnerabilities -- buffer overreads -- that occur in practice and that can be exploited to read parts of the memory contents of a process running a vulnerable application. We describe in detail how to exploit an application protected by both ASLR and stack canaries, if the application contains both a buffer overread and a buffer overflow vulnerability. We also provide a detailed discussion of how this vulnerability affects other, less widely deployed probabilistic countermeasures such as memory obfuscation and instruction set randomization.

Fides: selectively hardening software application components against kernel-level or process-level malware

Protecting commodity operating systems against software exploits is known to be challenging, because of their sheer size. The same goes for key software applications such as web browsers or mail clients. As a consequence, a significant fraction of internet-connected computers is infected with malware. To mitigate this threat, we propose a combined approach of (1) a run-time security architecture that can efficiently protect fine-grained software modules executing on a standard operating system, and (2) a compiler that compiles standard C source code modules to such protected binary modules. The offered security guarantees are significant: relying on a TCB of only a few thousand lines of code, we show that the power of arbitrary kernel-level or process-level malware is reduced to interacting with the module through the modules public API. With a proper API design and implementation, modules are fully protected. The run-time architecture can be loaded on demand and only incurs performance overhead when it is loaded. Benchmarks show that, once loaded, it incurs a 3.22% system-wide performance cost. For applications that make intensive use of protected modules, and hence benefit most of the security guarantees provided, the performance cost is up to 14%.

Efficient Isolation of Trusted Subsystems in Embedded Systems

Many embedded systems have relatively strong security requirements because they handle confidential data or support secure electronic transactions. A prototypical example are payment terminals. To ensure that sensitive data such as cryptographic keys cannot leak, security-critical parts of these systems are implemented as separate chips, and hence physically isolated from other parts of the system.

Secure Compilation to Modern Processors

We present a secure (fully abstract) compilation scheme to compile an object-based high-level language to low-level machine code. Full abstraction is achieved by relying on a fine-grained program counter-based memory access protection scheme, which is part of our low-level target language. We discuss why standard compilers fail to provide full abstraction and introduce enhancements needed to achieve this goal. We prove that our enhanced compilation scheme provides full abstraction from our high-level source language to our low-level target language. Lastly, we show by means of a prototype implementation that our low-level language with fine-grained memory access control can be realized efficiently on modern commodity platforms.

Secure Compilation to Protected Module Architectures

A fully abstract compiler prevents security features of the source language from being bypassed by an attacker operating at the target language level. Unfortunately, developing fully abstract compilers is very complex, and it is even more so when the target language is an untyped assembly language. To provide a fully abstract compiler that targets untyped assembly, it has been suggested to extend the target language with a protected module architecture—an assembly-level isolation mechanism which can be found in next-generation processors. This article provides a fully abstract compilation scheme whose source language is an object-oriented, high-level language and whose target language is such an extended assembly language. The source language enjoys features such as dynamic memory allocation and exceptions. Secure compilation of first-order method references, cross-package inheritance, and inner classes is also presented. Moreover, this article contains the formal proof of full abstraction of the compilation scheme. Measurements of the overhead introduced by the compilation scheme indicate that it is negligible.

ICE: a passive, high-speed, state-continuity scheme

The amount of trust that can be placed in commodity computing platforms is limited by the likelihood of vulnerabilities in their huge software stacks. Protected-module architectures, such as Intel SGX, provide an interesting alternative by isolating the execution of software modules. To minimize the amount of code that provides support for the protected-module architecture, persistent storage of (confidentiality and integrity protected) states of modules can be delegated to the untrusted operating system. But precautions should be taken to ensure state continuity: an attacker should not be able to cause a module to use stale states (a so-called rollback attack), and while the system is not under attack, a module should always be able to make progress, even when the system could crash or lose power at unexpected, random points in time (i.e., the system should be crash resilient). Providing state-continuity support is non-trivial as many algorithms are vulnerable to attack, require on-chip non-volatile memory, wear-out existing off-chip secure non-volatile memory and/or are too slow for many applications. We present ICE, a system and algorithm providing state-continuity guarantees to protected modules. ICEs novelty lies in the facts that (1) it does not rely on secure non-volatile storage for every state update (e.g., the slow TPM chip). (2) ICE is a passive security measure. An attacker interrupting the main power supply or any other source of power, cannot break state-continuity. (3) Benchmarks show that ICE already enables state-continuous updates almost 5x faster than writing to TPM NVRAM. With dedicated hardware, performance can be increased 2 orders of magnitude. ICEs security properties are guaranteed by means of a machine-checked proof and a prototype implementation is evaluated on commodity hardware.

Protected Software Module Architectures

A significant fraction of Internet-connected computing devices is infected with malware. With the increased connectivity and software extensibility of embedded and industrial devices, this threat is now also relevant for our industrial infrastructure and our personal environments. Since many of these devices interact with remote parties for security-critical or privacy sensitive transactions, it is important to develop security architectures that allow a stakeholder to assess the trustworthiness of a computing device, and that allow such stakeholders to securely execute software on that device. Over the past decade, the security research community has proposed and evaluated such architectures. Important and promising examples are protected software module architectures. These architectures support the secure execution of small protected software modules even on devices that are malware infected. They also make it possible for remote parties to collect trust evidence about a device; the remote party can use the security architecture to collect measurements that give assurance that the device is in a trustworthy state.

Mitigating Password Database Breaches with Intel SGX

In order to prevent rainbow attacks against a stolen password database, most passwords are appended with a unique salt before hashing them as to make the password random and more secure. However, the decreasing cost of hardware has made it feasible to perform brute force attacks by guessing the passwords (even when extended with their salt). Recently Intel has made processors with Intel SGX commercially available. This security technology enables developers to (1) completely isolate code and data running in an SGX enclave from untrusted code running at any privilege layer and (2) prevent data sealed to an enclave from being accessed on any other machine. We propose to add a key to the password (and salt) before they are hashed. By calculating the hash within an enclave, the key never leaves the enclave. This provides much stronger protection; offline attacks are infeasible without knowledge of the key. Online attacks on the other hand are much easier to defend against.

SGX-Step: A Practical Attack Framework for Precise Enclave Execution Control

Protected module architectures such as Intel SGX hold the promise of protecting sensitive computations from a potentially compromised operating system. Recent research convincingly demonstrated, however, that SGXs strengthened adversary model also gives rise to to a new class of powerful, low-noise side-channel attacks leveraging first-rate control over hardware. These attacks commonly rely on frequent enclave preemptions to obtain fine-grained side-channel observations. A maximal temporal resolution is achieved when the victim state is measured after every instruction. Current state-of-the-art enclave execution control schemes, however, do not generally achieve such instruction-level granularity. This paper presents SGX-Step, an open-source Linux kernel framework that allows an untrusted host process to configure APIC timer interrupts and track page table entries directly from user space. We contribute and evaluate an improved approach to single-step enclaved execution at instruction-level granularity, and we show how SGX-Step enables several new or improved attacks. Finally, we discuss its implications for the design of effective defense mechanisms.

Salus: Kernel support for secure process compartments

Consumer devices are increasingly being used to perform security and privacy critical tasks. The software used to perform these tasks is often vulnerable to attacks, due to bugs in the application itself or in included software libraries. Recent work proposes the isolation of security-sensitive parts of applications into protected modules, each of which can be accessed only through a predefined public interface. But most parts of an application can be considered security-sensitive at some level, and an attacker who is able to gain inapplication level access may be able to abuse services from protected modules. We propose Salus, a Linux kernel modification that provides a novel approach for partitioning processes into isolated compartments sharing the same address space. Salus significantly reduces the impact of insecure interfaces and vulnerable compartments by enabling compartments (1) to restrict the system calls they are allowed to perform, (2) to authenticate their callers and callees and (3) to enforce that they can only be accessed via unforgeable references. We describe the design of Salus, report on a prototype implementation and evaluate it in terms of security and performance. We show that Salus provides a significant security improvement with a low performance overhead, without relying on any non-standard hardware support.