The revelations about the Spectre and Meltdown vulnerabilities affecting millions of processors around the world has raised a huge number of questions for many people. While businesses and large organizations are rushing to ensure that their systems -- and their data -- are protected, the average computer user has been left wondering what on Earth is going on.
While there are a lot of very technical write-ups about the implications of the Spectre and Meltdown bugs, as well as explanations of just how the exploit works, the average Joe has been left somewhat in the dark. To try to remedy this, Google has answered a series of questions relating to the security issues.
In a blog post by senior security engineer, Matt Linton, and Matthew O'Connor look at Meltdown and Spectre taking Google customers into consideration. The post comes about because of, as Google puts it, the "confusion" surrounding the vulnerabilities.
Project Zero described three variants of this new class of speculative execution attack. Variant 1 and Variant 2 have been referred to as "Spectre." Variant 3 has been referred to as "Meltdown." Most vendors are referring to them by Common Vulnerabilities and Exposures aka "CVE" labels, which are an industry standard way of identifying vulnerabilities.
There's no single fix for all three attack variants; each requires protection individually.
Here's an overview of each variant:
- Variant 2 (CVE-2017-5715), "branch target injection." This variant may either be fixed by a CPU microcode update from the CPU vendor, or by applying a software protection called "Retpoline" to binaries where concern about information leakage is present. This variant is currently the basis for concern around Cloud Virtualization and "Hypervisor Bypass" concerns that affect entire systems.
- Variant 3 (CVE-2017-5754), "rogue data cache load." This variant is the basis behind the discussion around "KPTI," or "Kernel Page Table Isolation." When an attacker already has the ability to run code on a system, they can access memory which they do not have permission to access.
We already know that Google was aware of the vulnerabilities because of Project Zero, and that it took steps to secure its own products against them. The company addresses concerns that some of its customers have expressed that they have not been prompted to reboot their instance of Google Cloud Platform. It points out that the platform's architecture is such that live migration allows for reboot-free patching.
The post goes on to explain that Google's products are fully protected against the second variant of Spectre, but says that it is rather more difficult to secure against the first variant:
Variant 1 is the basis behind claims that Spectre is nearly impossible to protect against. The difficulty is that Variant 1 affects individual software binaries, so it must be handled by discovering and addressing exploits within each binary.
Risks that Variant 1 would pose to the infrastructure underpinning Google Cloud are addressed by the multiple security controls that make up our layered "defense in depth" security posture. Because Google is in full control of our infrastructure from the hardware up to our secure software development practices, our infrastructure is protected against Variant 1. You can read more about the security foundations of our infrastructure in our whitepaper.
We work continuously to stay ahead of the constantly-evolving threat landscape and will continue to roll out additional protections to address potential risks.
Addressing concerns about the slow-down after the application of vulnerability patches, Google says that it has detected "negligible impact on performance after applying remediations." Echoing Intel's statement that any performance degradation could be mitigated against over time, Google says:
There are many conflicting reports about patch impacts being publicly discussed. In some cases, people have published results of tests that focus solely on making API calls to the operating system, which does not represent the real-world scenario that customer software will encounter. There's no substitute for testing to determine for yourself what performance you can expect in your actual situation. We believe solutions exist that introduce minimal performance impact, and expect such techniques will be adopted by software vendors over time. We designed and tested our mitigations for this issue to have minimal performance impact, and the rollout has been uneventful.
Take a look at the full blog post for more details.