After several decades of defensive research against the exploitation of memory errors, a wide range of techniques has been proposed, yet no silver bullet has been found. Multi-Variant eXecution (MVX) is one promising proposal for defending against a wide range of known and potentially unknown attacks. MVX systems run multiple program variants in parallel on the same inputs while monitoring their behavior and deduplicating their outputs. By constructing these program variants using automated software diversity techniques, we can ensure that the variants behave identically under normal operating conditions but diverge when attacked. The MVX system detects these divergences and reacts appropriately.State-of-the-art MVX systems have several fundamental problems that inhibit their real-world adoption. First, they often require full source code availability to construct variants and eliminate non-deterministic program behavior. Second, they incur significant resource overhead that linearly increases with the number of variants running in parallel.We propose Partial Multi-Variant eXecution (PMVX), a technique that can mitigate these problems by limiting the scope of MVX to certain well-delineated parts of a target application and by running the rest of the application in Single-Variant eXecution (SVX) mode. PMVX relaxes the source code availability requirement of traditional MVX systems and yields substantially reduced resource consumption while maintaining the strong security guarantees of these systems. However, PMVX implementations must address the non-trivial problem of ensuring all variants are in equivalent states whenever they switch from SVX to MVX mode.We designed and implemented a proof-of-concept PMVX system called FORTDIVIDE that solves this state-equivalency problem using state migration and resynchronization. We thoroughly evaluated the security and performance of our system as a whole, and of our state migration and synchro-nization mechanisms in isolation. We conclude that PMVX has great potential but needs to be applied with the utmost care since the added overhead of state resynchronization can quickly outweigh the benefits of running in SVX mode.

Multi-variant execution (MVX) is a low-friction approach to increase the security of critical software applications. MVX systems execute multiple diversified implementations of the same software in lockstep on the same inputs, while monitoring each variant’s behavior. MVX systems can detect attacks quickly and with high probability, because low-level vulnerabilities are unlikely to manifest in precisely the same manner across sufficiently diversified variants. Existing MVX systems terminate execution when they detect a divergence in behavior between variants.In this paper, we present A8,1which we believe is the first full-scale survivable MVX system that not only detects attacks as they happen, but is also able to recover from them. Our implementation is comprised of two parts, an MVX portion that leverages the natural heterogeneity of variants running on diverse platforms (ARM64 and x86_64), and a checkpoint/restore portion that periodically creates snapshots of the variants’ states and forces variants to roll back to those snapshots upon detection of any irregular behavior. In this way, A8achieves availability even in the face of continuous remote attacks.We consider several design choices and evaluate their security and performance trade-offs using microbenchmarks. Chiefly among these, we devise a system call interposition and monitor implementation approach that provides secure isolation of the MVX monitor, minimal kernel changes (small privileged TCB), and low overheads – a combination not before seen in the context of MVX. We also perform a real-world evaluation of our system on two popular web servers, lighttpd and nginx, and the database server redis, which are able to maintain 53%-71% of their throughput compared to native execution.

Syscall interposition is crucial for tools that monitor/modify application behavior. Mainstream OSes have, therefore, provided syscall interposition APIs for years, but these often incur prohibitive performance penalties in syscall-intensive applications. Recent work showed how to reduce this overhead by rewriting syscall instructions11Throughout this paper, we will use the term “syscall instruction” to refer to both the x86 SYSCALL and SYSENTER instructions. to invoke the interposer directly, avoiding expensive mode/context switches. However, these methods may not locate/rewrite all relevant instructions, which is essential for many applications. Our key insight is to combine the aforementioned techniques to efficiently intercept all system calls. We present lazypoline, a tool that uses slow kernel interfaces to exhaustively locate valid syscall instructions upon their first use, and then lazily rewrites them to invoke the interposer directly in all subsequent executions. We extensively evaluate lazypoline on micro- and macrobenchmarks and show that it is non-intrusive, fully exhaustive, and it achieves the efficiency of pure rewriting, even for datacenter-scale syscall-intensive workloads.

Fitness tracking social networks such as Strava allow users to record sports activities and share them publicly. Sharing encourages peer interaction but also constitutes a risk, because an activity's start or finish may inadvertently reveal privacy-sensitive locations such as a home or workplace. To mitigate this risk, networks introduced endpoint privacy zones (EPZs), which hide track portions around protected locations. In this paper, we show that EPZ implementations of major services remain vulnerable to inference attacks that significantly reduce the effective anonymity provided by the EPZ, and even reveal the protected location. Our attack leverages distance information leaked in activity metadata, street grid data, and the locations of the entry points into the EPZ. This yields a constrained search space where we use regression analysis to predict protected locations. Our evaluation on 1.4 million Strava activities shows that our attack discovers the protected location for up to 85% of EPZs. Larger EPZs reduce the performance of our attack, while geographically dispersed activities in sparser street grids yield better performance. We propose six countermeasures, that, however, come with a usability trade-off, and responsibly disclosed our findings and countermeasures to the major networks.

After more than twenty-five years of research, memory safety violations remain one of the major causes of security vulnerabilities in real-world software. Memory-safe languages, like Rust, have demonstrated that compiler technology can assist developers in writing efficient low-level code without the risk of memory corruption. However, many memory-safe languages still have to interface with unsafe code to some extent, which opens up the possibility for attackers to exploit memory-corruption vulnerabilities in the unsafe part of the system and subvert the safety guarantees provided by the memory-safe language.

Multi-Variant Execution Environments (MVEEs) are a powerful tool for protecting legacy software against memory corruption attacks. MVEEs employ software diversity to run multiple variants of the same program in lockstep, whilst providing them with the same inputs and comparing their behavior. Well-constructed variants will behave equivalently under normal operating conditions but diverge when under attack. The MVEE detects these divergences and takes action before compromised variants can damage the host system.

Memory Protection Keys for Userspace (PKU) is a recent hardware feature that allows programs to assign virtual memory pages to protection domains, and to change domain access permissions using inexpensive, unprivileged instructions. Several in-process memory isolation approaches leverage this feature to prevent untrusted code from accessing sensitive program state and data. Typically, PKU-based isolation schemes need to be used in conjunction with mitigations such as CFI because untrusted code, when compromised, can otherwise bypass the PKU access permissions using unprivileged instructions or operating system APIs.

Modern operating system kernels deploy Kernel Address Space Layout Randomization (KASLR) to mitigate control-flow hijacking attacks. KASLR randomizes the base addresses of the kernel's code and data segments. However, it randomizes both with a single offset and does not randomize the internal layout of either of these segments, so relative addresses remain known to adversaries. If the kernel discloses a single code or global data pointer, an adversary can therefore infer the entire layout of the kernel's code segment and bypass KASLR. In this paper, we present Kernel Address Leak Detector (KALD), a tool that finds direct disclosure vulnerabilities by statically analyzing the kernel source code. KALD can analyze the source code of modern operating system kernels and find previously unreported leaks. KALD compiles a list of functions that can leak information to user-space accessible locations, and it uses the results of a points-to analysis to determine whether individual invocations of such functions can disclose kernel pointers. We show that KALD successfully detects several direct disclosure vulnerabilities in the Linux kernel and that it is flexible enough to be useful in practice.

The widespread deployment of exploit mitigations such as CFI and shadow stacks are making code-reuse attacks increasingly difficult. This has forced adversaries to consider data-only attacks against which the venerable ASLR remains the primary deployed defense.Data-Space Randomization (DSR) techniques raise the bar against data-only attacks by making it harder for adversaries to inject malicious data flows into vulnerable applications. DSR works by masking memory load and store instructions. Masks are chosen (i) to not interfere with intended data flows and (ii) such that masking likely interferes with unintended flows introduced by malicious program inputs.

Binary lifting and recompilation allow a wide range of install-time program transformations, such as security hardening, deobfuscation, and reoptimization. Existing binary lifting tools are based on static disassembly and thus have to rely on heuristics to disassemble binaries.

The C and C++ programming languages are notoriously insecure yet remain indispensable. Developers therefore resort to a multi-pronged approach to find security issues before adversaries. These include manual, static, and dynamic program analysis. Dynamic bug finding tools-henceforth "sanitizers"-can find bugs that elude other types of analysis because they observe the actual execution of a program, and can therefore directly observe incorrect program behavior as it happens. A vast number of sanitizers have been prototyped by academics and refined by practitioners. We provide a systematic overview of sanitizers with an emphasis on their role in finding security issues. Specifically, we taxonomize the available tools and the security vulnerabilities they cover, describe their performance and compatibility properties, and highlight various trade-offs.

Scientific applications are ideal candidates for the "heterogeneous computing" paradigm, in which parts of a computation are "offloaded" to available accelerator hardware such as GPUs. However, when such applications are written in dynamic languages such as Python or R, as they increasingly are, things become less straightforward. The same flexibility that makes these languages so appealing to programmers also significantly complicates the problem of automatically and transparently partitioning a program's execution between a CPU and available accelerator hardware without having to rely on programmer annotations. A common way of handling the features of dynamic languages is by introducing speculation in conjunction with guards to ascertain the validity of assumptions made in the speculative computation. Unfortunately, a single guard violation during the execution of "offloaded" code may result in a huge performance penalty and necessitate the complete re-execution of the offloaded computation. In the case of dynamic languages, this problem is compounded by the fact that a full compiler analysis is not always possible ahead of time. This paper presents MegaGuards, a new approach for speculatively executing dynamic languages on heterogeneous platforms in a fully automatic and transparent manner. Our method translates each target loop into a single static region devoid of any dynamic type features. The dynamic parts are instead handled by a construct that we call a mega guard which checks all the speculative assumptions ahead of its corresponding static region. Notably, the advantage of MegaGuards is not limited to heterogeneous computing; because it removes guards from compute-intensive loops, the approach also improves sequential performance. We have implemented MegaGuards along with an automatic loop parallelization backend in ZipPy, a Python Virtual Machine. The results of a careful and detailed evaluation reveal very significant speedups of an order of magnitude on average with a maximum speedup of up to two orders of magnitudes when compared to the original ZipPy performance as a baseline. These results demonstrate the potential for applying heterogeneous computing to dynamic languages.

Exploit mitigations, by themselves, do not stop determined and well-resourced adversaries from compromising vulnerable software through memory corruption. Multi-variant execution environments (MVEEs) add additional assurance by executing multiple, diversified copies (variants) of the same program in lockstep while monitoring their behavior for signs of attacks (divergence). While executing multiple copies of the same program requires additional computational resources, modern MVEEs run many workloads at near-native speed and can detect adversaries before they leak secrets or achieve persistence on the host system.

In this paper, we present disjoint code layouts (DCL), a technique that complements multi-variant execution[1]and W$\oplus$X protection to effectively immunize programs against control flow hijacking exploits such as return oriented programming (ROP)[2]and return-to-libc attacks[3]. DCL improves upon address space partitioning (ASP), an earlier technique presented to defeat memory exploits. Unlike ASP, our solution keeps the full virtual address space available to the protected program. Additionally, our combination of DCL with Multi-Variant Execution is transparent to both the user and the programmer and incurs much less overhead than other ROP defense tools, both in terms of run time and memory footprint.

Code-reuse attacks continue to evolve and remain a severe threat to modern software. Recent research has proposed a variety of defenses with differing security, efficiency, and practicality characteristics. Whereas the majority of these solutions focus on specific code-reuse attack variants such as return-oriented programming (ROP), other attack variants that reuse whole functions, such as the classic return-into-libc, have received much less attention. Mitigating function-level code reuse is highly challenging because one needs to distinguish a legitimate call to a function from an illegitimate one. In fact, the recent counterfeit object-oriented programming (COOP) attack demonstrated that the majority of code-reuse defenses can be bypassed by reusing dynamically bound functions, i.e., functions that are accessed through global offset tables and virtual function tables, respectively.