ret2spec: Speculative Execution Using Return Stack Buffers

Speculative execution is an optimization technique that has been part of CPUs for over a decade. It predicts the outcome and target of branch instructions to avoid stalling the execution pipeline. However, until recently, the security implications of speculative code execution have not been studied. In this paper, we investigate a special type of branch predictor that is responsible for predicting return addresses. To the best of our knowledge, we are the first to study return address predictors and their consequences for the security of modern software. In our work, we show how return stack buffers (RSBs), the core unit of return address predictors, can be used to trigger misspeculations. Based on this knowledge, we propose two new attack variants using RSBs that give attackers similar capabilities as the documented Spectre attacks. We show how local attackers can gain arbitrary speculative code execution across processes, e.g., to leak passwords another user enters on a shared system. Our evaluation showed that the recent Spectre countermeasures deployed in operating systems can also cover such RSB-based cross-process attacks. Yet we then demonstrate that attackers can trigger misspeculation in JIT environments in order to leak arbitrary memory content of browser processes. Reading outside the sandboxed memory region with JIT-compiled code is still possible with 80\% accuracy on average.Comment: Updating to the cam-ready version and adding reference to the original pape

Software Fault Isolation: a first step towards Microreboot in legacy C applications

Microreboot is an attractive technique for recovering an application after a non-malicious failure or deliberate integrity breach even in cases where the precise cause of the failure or breach are not known. Unfortunately, Microreboot functionality has so far been demonstrated only with Java applications meeting a set of peculiar Crash-only architectural requirements. This report describes a method of using Software Fault Isolation techniques to meet some of these architectural requirements in C programs, thereby taking a first step towards making Microreboot available for retrofit in legacy C applications

Defense and Attack Techniques against File-based TOCTOU Vulnerabilities: a Systematic Review

File-based Time-of-Check to Time-of-Use (TOCTOU) race conditions are a well-known type of security vulnerability. A wide variety of techniques have been proposed to detect, mitigate, avoid, and exploit these vulnerabilities over the past 35 years. However, despite these research efforts, TOCTOU vulnerabilities remain unsolved due to their non-deterministic nature and the particularities of the different filesystems involved in running vulnerable programs, especially in Unix-like operating system environments. In this paper, we present a systematic literature review on defense and attack techniques related to the file-based TOCTOU vulnerability. We apply a reproducible methodology to search, filter, and analyze the most relevant research proposals to define a global and understandable vision of existing solutions. The results of this analysis are finally used to discuss future research directions that can be explored to move towards a universal solution to this type of vulnerability. Autho

Inherent Limitations of Hybrid Transactional Memory

Several Hybrid Transactional Memory (HyTM) schemes have recently been proposed to complement the fast, but best-effort, nature of Hardware Transactional Memory (HTM) with a slow, reliable software backup. However, the fundamental limitations of building a HyTM with nontrivial concurrency between hardware and software transactions are still not well understood. In this paper, we propose a general model for HyTM implementations, which captures the ability of hardware transactions to buffer memory accesses, and allows us to formally quantify and analyze the amount of overhead (instrumentation) of a HyTM scheme. We prove the following: (1) it is impossible to build a strictly serializable HyTM implementation that has both uninstrumented reads and writes, even for weak progress guarantees, and (2) under reasonable assumptions, in any opaque progressive HyTM, a hardware transaction must incur instrumentation costs linear in the size of its data set. We further provide two upper bound implementations whose instrumentation costs are optimal with respect to their progress guarantees. In sum, this paper captures for the first time an inherent trade-off between the degree of concurrency a HyTM provides between hardware and software transactions, and the amount of instrumentation overhead the implementation must incur