Earlier this week, security vulnerabilities, dubbed ‘Spectre’ and ‘Meltdown’, made news headlines around the world. Various manufacturers have since then have rolled out patches to fix the issues. Some of them have even described these two flaws to be not as threatening as the media is portraying.
However, various reports across the Internet have been discussing the issue in different ways and if you are unable to understand what the actual problem was and what does it mean for computers across the world, then Google’s detailed explanation about Spectre and Meltdown should clear out your doubts.
What are “Spectre” and “Meltdown”?
Last year, Google’s Project Zero team discovered serious security flaws caused by “speculative execution,” a technique used by most modern processors (CPUs) to optimise performance.
Independent researchers separately discovered and named these vulnerabilities “Spectre” and “Meltdown.”
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 1 (CVE-2017-5753), “bounds check bypass.” This vulnerability affects specific sequences within compiled applications, which must be addressed on a per-binary basis. This variant is currently the basis for concern around browser attacks, Javascript exploitation and vulnerabilities within individual binaries.
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 Virtualisation 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.
Am I protected from Spectre and Meltdown?
Google’s engineering teams began working to protect customers from these vulnerabilities upon learning of them in June 2017. G Suite and Google Cloud Platform (GCP) are updated to protect against all known attack vectors. Some customers may worry that they have not been protected since they were not asked to reboot their instance. Google Cloud is architected in a manner that enables us to update the environment while providing operational continuity for our customers. Via live migration, we can patch our infrastructure without requiring customers to reboot their instances.
Customers who use their own operating systems with Google Cloud services should continue to follow security best practices and apply security updates to their images just as they would for any other operating system vulnerability.
Is Spectre nearly impossible to protect against?
There has been a significant concern in particular about “Spectre.” The use of the name “Spectre” to refer to both Variants 1 and 2 has caused some confusion over whether it's “fixed” or not.
Google Cloud instances are protected against all known inter-VM attacks, regardless of the patch status of the guest environments, and attackers do not have access to any other customers’ data as a result of these vulnerabilities. Google Cloud and other public clouds use virtualisation technology to isolate neighbouring customer workloads. A virtualisation component known as a hypervisor connects the physical machine to virtual machines. This hypervisor can be updated to address Variant 2 threats. Google Cloud has updated its hypervisor using “Retpoline,” which addresses all currently known Variant 2 attack methods.
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 “defence in depth” security posture. Because Google is in full control of our infrastructure from the hardware up to our secure software development practices, its infrastructure is protected against Variant 1.
We work continuously to stay ahead of the constantly evolving threat landscape and will continue to roll out additional protections to address potential risks.
As a user of the public cloud, am I more vulnerable to Spectre and Meltdown than others?
In many respects, public cloud users are better-protected from security vulnerabilities that are users of traditional datacenter-hosted applications. Security best practices rely on discovering vulnerabilities early and patching them promptly and completely. Each of these activities is aided by the scale and automation that top public cloud providers can offer — for example, few companies maintain a several-hundred-person security research team to find vulnerabilities and patch them before they're discovered by others or disclosed. Having the ability to update millions of servers in days, without causing user disruption or requiring maintenance windows, is a difficult technology to develop but it allows patches and updates to be deployed quickly after they become available, and without user disruption that can damage productivity.
Spectre and Meltdown are new and troubling vulnerabilities, but it’s important to remember that there are many different types of threats that Google (and other cloud providers) protect against every single day. Google’s cloud infrastructure doesn’t rely on any single technology to make it secure. Our stack builds security through progressive layers that deliver defence in depth. From the physical premises to the purpose-built servers, networking equipment, and custom security chips to the low-level software stack running on every machine, our entire hardware infrastructure is Google-controlled, -secured, -built and -hardened.
Is performance impacted?
On most of Google’s workloads, including their cloud infrastructure, there’s negligible impact on performance after applying remediations.
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. Solutions exist that introduce minimal performance impact, and expect such techniques will be adopted by software vendors over time. Google designed and tested their mitigations for this issue to have a minimal performance impact, and the rollout has been uneventful.
(With inputs from Google)
(Also published on Deccan Chronicle)
