Oleksii Oleksenko

CR
5papers
262citations
Novelty56%
AI Score27

5 Papers

CRMay 14, 2021
Revizor: Testing Black-box CPUs against Speculation Contracts

Oleksii Oleksenko, Christof Fetzer, Boris Köpf et al.

Speculative vulnerabilities such as Spectre and Meltdown expose speculative execution state that can be exploited to leak information across security domains via side-channels. Such vulnerabilities often stay undetected for a long time as we lack the tools for systematic testing of CPUs to find them. In this paper, we propose an approach to automatically detect microarchitectural information leakage in commercial black-box CPUs. We build on speculation contracts, which we employ to specify the permitted side effects of program execution on the CPU's microarchitectural state. We propose a Model-based Relational Testing (MRT) technique to empirically assess the CPU compliance with these specifications. We implement MRT in a testing framework called Revizor, and showcase its effectiveness on real Intel x86 CPUs. Revizor automatically detects violations of a rich set of contracts, or indicates their absence. A highlight of our findings is that Revizor managed to automatically surface Spectre, MDS, and LVI, as well as several previously unknown variants.

DCJan 16, 2021
T-Lease: A Trusted Lease Primitive for Distributed Systems

Bohdan Trach, Rasha Faqeh, Oleksii Oleksenko et al.

A lease is an important primitive for building distributed protocols, and it is ubiquitously employed in distributed systems. However, the scope of the classic lease abstraction is restricted to the trusted computing infrastructure. Unfortunately, this important primitive cannot be employed in the untrusted computing infrastructure because the trusted execution environments (TEEs) do not provide a trusted time source. In the untrusted environment, an adversary can easily manipulate the system clock to violate the correctness properties of lease-based systems. We tackle this problem by introducing trusted lease -- a lease that maintains its correctness properties even in the presence of a clock-manipulating attacker. To achieve these properties, we follow a "trust but verify" approach for an untrusted timer, and transform it into a trusted timing primitive by leveraging two hardware-assisted ISA extensions (Intel TSX and SGX) available in commodity CPUs. We provide a design and implementation of trusted lease in a system called T-Lease -- the first trusted lease system that achieves high security, performance, and precision. For the application developers, T-Lease exposes an easy-to-use generic APIs that facilitate its usage to build a wide range of distributed protocols.

CRMay 24, 2019
SpecFuzz: Bringing Spectre-type vulnerabilities to the surface

Oleksii Oleksenko, Bohdan Trach, Mark Silberstein et al.

SpecFuzz is the first tool that enables dynamic testing for speculative execution vulnerabilities (e.g., Spectre). The key is a novel concept of speculation exposure: The program is instrumented to simulate speculative execution in software by forcefully executing the code paths that could be triggered due to mispredictions, thereby making the speculative memory accesses visible to integrity checkers (e.g., AddressSanitizer). Combined with the conventional fuzzing techniques, speculation exposure enables more precise identification of potential vulnerabilities compared to state-of-the-art static analyzers. Our prototype for detecting Spectre V1 vulnerabilities successfully identifies all known variations of Spectre V1 and decreases the mitigation overheads across the evaluated applications, reducing the amount of instrumented branches by up to 77% given a sufficient test coverage.

CRMay 22, 2018
You Shall Not Bypass: Employing data dependencies to prevent Bounds Check Bypass

Oleksii Oleksenko, Bohdan Trach, Tobias Reiher et al.

A recent discovery of a new class of microarchitectural attacks called Spectre picked up the attention of the security community as these attacks can circumvent many traditional mechanisms of defense. One of the attacks---Bounds Check Bypass---can neither be efficiently solved on system nor architectural levels and requires changes in the application itself. So far, the proposed mitigations involved serialization, which reduces the usage of CPU resources and causes high overheads. In this report, we explore methods of delaying the vulnerable instructions without complete serialization. We discuss several ways of achieving it and compare them with Speculative Load Hardening, an existing solution based on a similar idea. The solutions of this type cause 60% overhead across Phoenix benchmark suite, which compares favorably to the full serialization causing 440% slowdown.

CRFeb 2, 2017
Intel MPX Explained: An Empirical Study of Intel MPX and Software-based Bounds Checking Approaches

Oleksii Oleksenko, Dmitrii Kuvaiskii, Pramod Bhatotia et al.

Memory-safety violations are a prevalent cause of both reliability and security vulnerabilities in systems software written in unsafe languages like C/C++. Unfortunately, all the existing software-based solutions to this problem exhibit high performance overheads preventing them from wide adoption in production runs. To address this issue, Intel recently released a new ISA extension - Memory Protection Extensions (Intel MPX), a hardware-assisted full-stack solution to protect against memory safety violations. In this work, we perform an exhaustive study of the Intel MPX architecture to understand its advantages and caveats. We base our study along three dimensions: (a) performance overheads, (b) security guarantees, and (c) usability issues. To put our results in perspective, we compare Intel MPX with three prominent software-based approaches: (1) trip-wire - AddressSanitizer, (2) object-based - SAFECode, and (3) pointer-based - SoftBound. Our main conclusion is that Intel MPX is a promising technique that is not yet practical for widespread adoption. Intel MPX's performance overheads are still high (roughly 50% on average), and the supporting infrastructure has bugs which may cause compilation or runtime errors. Moreover, we showcase the design limitations of Intel MPX: it cannot detect temporal errors, may have false positives and false negatives in multithreaded code, and its restrictions on memory layout require substantial code changes for some programs.