As you may know, several serious exploits/bugs have been introduced into modern CPUs, mainly Intel-based CPUs (which ironically have been touted and pushed by Intel as the most secure for cloud-based applications, and run about 90% of the cloud platform deployed world-wide), that allows successful attackers to access data that has been stored in the CPU's cache, whether their processes have the correct security levels to view said information.
These vulnerabilities have huge implications for cloud applications (especially Meltdown, which we'll talk about now), as VMs running in the cloud could gain access to another VM's information (if that information was cached in the CPU). This violates safe-pracetices, as well as almost every security certification you can think of (PCI, HIPPA, SOX, HITRUST, etc). Meltdown breaks the most fundamental isolation between user applications and the operating system, allowing a program to access the memory, and thus also the secrets, of other programs and the operating system.
Note that even though this does allow a VM to access another VM's data possibly, if you're running a private cloud, where all VMs are part of your application, and all VMs have the same security levels, this becomes almost an inconsequential issue. To exploit the issue, the attacker would need to breach your security and gain access to a server within your cloud, and if they've gone that far, there are MUCH easier ways to gain that data once they're in your environment. Meltdown has far greater impact on the public cloud than the private cloud, although it still needs to be patched.
Spectre, however, breaks the isolation between different applications in that it allows an attacker to trick error-free programs, which follow best practices, into leaking their secrets. In fact, the safety checks and error-catching of said best-practices, actually increase the attack surface and may make applications more susceptible to Spectre. It's much harder to exploit than Meltdown, but harder to mitigate. It's possible to prevent specific, known exploits based on Spectre, through software patches and some creative web application firewalling.
What CPUs are Affected by Spectre/Meltdown?
The Meltdown flaw affects Intel CPUs, and Spectre impacts ALL modern processors, including ones from Intel, Advanced Micro Devices and ARM. "Meltdown breaks the mechanism that keeps applications from accessing arbitrary system memory; consequently, applications can access system memory,” according to an advisory concerning the flaw. There are some specialized CPUs that are immune, such as the Raspberry Pi, some IoT CPUs, ect, but if it's a desktop or server CPU ... it's vulnerable, no matter how new.
Spectre, meanwhile, abuses a CPU function in modern processors that use something known as "speculative execution" to maximize chip performance. It's not yet known if attackers have used either vulnerability to exploit users, and the exploitation of Meltdown or Spectre doesn't leave any evidence in traditional log files.
Some Things We Know (Very Important)
These are Local Attacks
Both Meltdown and Spectre are local attacks that require executing malicious code on a target machine. This means that these attacks are not (directly) drive-by style remote code execution attacks – think Nimda or Code Red – and that systems cannot be attacked merely by being connected to a network, through SQL injection, or through web forms or chat portals. So we go back to the statement we made earlier: To exploit the issue, the attacker would need to breach your security and gain access to a server within your cloud, and if they've gone that far, there are MUCH easier ways to gain that data once they're in your environment.
These are Read-Only (Information Disclosure) Attacks
Along with not directly being remotely exploitable, even if Meltdown and Spectre attacks are executed on a local system, the nature of the exploit is that these are read-only attacks. That is, they can only read information from a system. They cannot directly force code execution in the OS kernel, in other virtual machines, or other programs.
There Have been NO Observed Active Deployments
So far these exploits, although serious, have only been pulled off in controlled, lab environments. No group or person has managed, and several security groups have tried, with permission, on active systems, to pull off these attacks in a live environment. And again, we must stress, local access HAS to be obtained, and by the time the person gets this access, you're breached, and there are MANY easier ways at that point to get your data.
The Principal Threat is to Shared Hosting Environments
Given the above, these attacks are most threatening to shared hosting environments, where multiple users are all capable of executing code on a single system. As a result, cloud service providers like us (and Amazon, Microsoft, etc ... as an Amazon Security Partner, we had access to their patches well before Microsoft rolled theirs) have already deployed attack mitigation efforts to their services. Individual systems and devices, by comparison, have a much lower practical risk. An attacker still needs to get malicious code executing on an individual system before they can run an attack; and if an attacker can do that, then an individual system is already in a bad position to begin with.
Meltdown and Spectre can be Mitigated in Software
Because the root issues at the heart of Meltdown and Spectre are at the hardware level, ideally, that hardware needs to be replaced. As replacing 20 years of systems isn’t remotely practical however, like other CPU errata it can be mitigated in a combination of CPU microcode and operating system updates. Vendors like Microsoft, Apple, and the Linux distros are already in the process of rolling out some of these fixes, and Microsoft has rolled several patches already through Windows Update (although there are serious repercussions with these patches).
Mitigating Meltdown will have a Performance Impact
Basically, the mitigation efforts for Meltdown involve better separating user space programs from the OS kernel. As a result, context switches between the user space and the kernel will get more expensive. However the actual performance impact of this process is going to vary with the workload and the CPU architecture.
Unfortunately, web servers seem to be hit particularly hard for their processing load, and we're seeing 20%-35% CPU degredation across our clouds, both private and public (and our hybrid customers with local servers on site and servers in our cloud) are reporting similar numbers on their own hardware. This means many
customers may need to add additional servers to pick up this loss in hardware processing power.
Spectre is a Wildcard as to how Severe it Will Be
While Meltdown is the more immediate threat, how it works and how to mitigate it are fairly well documented. Spectre however is a definite wildcard right now. There are multiple proof of concept attacks as it stands, but more broadly speaking, Spectre attacks are a new class of attacks not quite like anything vendors have seen before. As a result no one is completely confident that they understand the full security ramifications of the exploit. There is a risk that Spectre attacks can be used for more than what’s currently understood.
What Can Users Do Right Now?
Finally, there’s the question of what system and device owners should do about the Meltdown and Spectre attacks. The fundamental weakness that allows these speculative execution attacks is in the hardware itself, so short of replacing devices, the problem cannot be truly solved. The only thing that can be done right now is to mitigate the problem with software and microcode patches that attempt to work-around the problem.
The solution then is a double-edged sword for users: there’s not much they can do, but there’s also not much they have to do. The software and microcode updates to mitigate these exploits will be distributed as software updates, so keeping your systems and mobile devices up-to-date with the latest OS version is the single most important step one can take. As mentioned earlier, everyone has or is in the process of rolling out the necessary software updates to help mitigate this. The flip side is that, short of a focused ion beam tool, there’s not much else for users to do. This is a problem whose resolution is going to be vendor-driven.
Monday, January 15, 2018