|author||Venkatesh Srinivas <firstname.lastname@example.org>||Fri Sep 25 03:02:14 2020 +0000|
|committer||Venkatesh Srinivas <email@example.com>||Fri Sep 25 03:02:14 2020 +0000|
Fuchsia: Turn safeside ret2spec tests into a library ret2spec is a class of Spectre V2-related speculative execution information leaks, where the contents of return address stacks are poisoned. Poisoned return address stacks can be used to cause sensitive code to (speculatively) execute attacker-controlled code, which can be used as a building block in infoleak attacks. Ret2spec attacks can be carried out within a process, across user/kernel boundaries on a CPU, and across processes. Safeside is a collection of demos of speculative execution attacks, including ret2spec; we plan to use its demos to test Fuchsia's speculative execution mitigations. Convert Safeside's standalone ret2spec demos into a library, so that Fuchsia-driven tests can use them. We do not have a test in-tree of ret2spec_ca (cross-address-space), but will adapt ret2spec_sa into one. Bug: 12540 Speculative Execution Mitigations. Bug: 33667 Spectre mitigations? Change-Id: I239a8ba1f1b73f6ef58b6baa2b1f54ac6f3c3cb3
SafeSide is a project to understand and mitigate software-observable side-channels: information leaks between software domains caused by implementation details outside the software abstraction.
Unlike other side-channel attacks -- e.g. measuring power use or electromagnetic emissions -- software-observable side-channels don't require physical access or proximity.
Our early focus is on transient execution attacks and leaks from software cryptography implementations.
This repository provides a home for:
Robust, portable examples that leak data through different side-channels under real-world conditions.
For more on building and running our examples, see the demos README.
References to research that describes what causes side-channels and how they behave.
Docs are here.
Ideas and prototypes for how to find and stop side-channel leaks.
This project is new and under active development. To start, we have a few examples of Spectre side-channel leaks and a collection of links we've found useful.
For more information on our plans and priorities, see our Roadmap.
This project is focused on defense. While we enthusiastically believe in the value of adversarial testing (e.g. red teaming) for securing software systems, this repository is not intended to advance the state of the art for attackers.
To that end, we have some ground rules:
No nonpublic attacks. This isn't the place to research new side-channels, discuss any embargoed or otherwise undisclosed vulnerabilities, or try to bypass currently-effective mitigations.
No exploits that leak interesting data. We want to show side-channels in action, but we will only leak synthetic data that we put there to be leaked.
These are the areas where we plan to spend our effort and where we think contributions will be most useful.
We‘re not satisfied with an archive of proof-of-concept apps. The examples in this repository should read like Knuth-style literate programs, making it abundantly clear how the infoleak functions end-to-end: what setup is strictly necessary; what implementation behaviors we’re relying on or working around; and what we've added to make the demonstration more robust.
This standard applies to our examples, the library code they share, and the support infrastructure we provide to get things running.
We're always on the lookout for ways we can make examples in this project simpler to understand. We expect that will most often mean better comments and better factoring of code. But sometimes it will mean step-function improvements through entirely new, more straightforward approaches.
These examples are each designed to exercise specific vulnerabilities, and they should produce consistent and useful results anywhere those leaks are present.
This could mean amplifying or cleaning up side-channel signal (on the producer or consumer side) or retrying on failure.
This project hopes to provide examples of every kind of software-observable side-channel. They should run in as many environments as they can to enable comprehensive testing of mitigations. We think we're off to a good start, but we hope to improve our coverage along several dimensions.
We should have examples embodying most or all known timing leak sources, including (non-exhaustively): Spectre (all variants), Meltdown, Speculative Store Bypass, L1 Terminal Fault (L1TF), and Microarchitectural Data Sampling (MDS).
Our examples should compile with GCC, Clang, and Microsoft Visual C++ (MSVC). (Stretch: ICC.)
Our examples should build and produce useful results on macOS, Windows, and Linux -- including, where possible, when those OSes are running virtualized. Eventually we also hope to provide something worth running on iOS and Android.
We intend to explore more virtualized scenarios over time, in which case we will want to cover a diversity of hypervisors and VMMs.
Our examples should cover known ways of establishing covert side-channels. Data or instruction cache timing are most popular, but we should also explore execution unit contention (SMoTherSpectre) or activation latency (NetSpectre).
We want to show information leaks across a variety of typical security boundaries. In what we think is roughly increasing order of difficulty:
We expect many of these examples will require turning off existing mitigations or security features that are widely deployed. When we want to demonstrate an attack that isn‘t possible on a modern, patched system, we’ll provide infrastructure to create an old, unpatched system.
We want examples that provide clear positive (or negative) results across a wide range of processor generations from different vendors across different architectures. That said, we'll also generally prioritize working examples for hardware with the broadest deployment.
We want to demonstrate timing leaks against analogues of different kinds of data-handling code: serialization, cryptographic algorithms, application business logic, etc.
We believe the robustness of our samples, and the usefulness of potential mitigations, can be evaluated by extracting metrics that can be compared across instances. Bandwidth -- correct bytes leaked per unit time -- seems like one obvious choice.
We want to make it easy to run many examples across many environments quickly and reproducibly. This supports our mission of enabling quantitative comparison, and should allow for a quick feedback loop for developers prototyping new software-based mitigations.
One of the goals of producing a broad set of examples is to be able to show the effectiveness of mitigations, so we also want to add infrastructure to build and test with existing mitigations enabled.
We eagerly welcome contributions. Please take a look at our contributing guidelines for more on how to engage with the project.
If you‘ve found a bug or think something’s missing, please file an issue.
For general discussion about side-channels or for questions about the project's goals and roadmap, use our
This is not an officially supported Google product.