Since Meltdown and Spectre were publicly disclosed earlier this month, there has been much confusion surrounding exactly how these attacks work, and what impact they may have on the enterprise. Though these vulnerabilities could pose a serious risk to the enterprise, I think we can probably hold short of a full-fledged panic, at least for now. Let’s take a look at what these two attacks really are, what solutions are available, and what they may ultimately mean for the enterprise.
Meltdown and Spectre exploit critical flaws in modern processors. Unlike most vulnerabilities, the vulnerabilities used by Meltdown and Spectre do not exist in software, but in the processors themselves. This is significant for many reasons. First, while it is possible to patch “around” these vulnerabilities, it is much more difficult to patch the vulnerabilities themselves. Second, although endpoint protection solutions may be able to detect methods used to deliver a payload which exploits the Meltdown or Spectre vulnerabilities, the execution of the exploits themselves are very hard to distinguish from normal processes and thus very difficult to detect heuristically. Finally, since these exploits are performed at the hardware level, the forensic artifacts often relied upon to investigate malware incidents are absent in these attacks.
While programs are typically not permitted to read data from memory sections outside their own address space, a malicious program can exploit Meltdown or Spectre to access regions of memory that the process should not otherwise have access to. This could include access to user credentials or hashes, private keys, sandbox escape, VM escape and access to other confidential information stored in memory.
So far, there are three specific vulnerabilities which are used in Meltdown or Spectre attacks:
• Variant 1: Bounds check bypass (CVE-2017-5753)
• Variant 2: Branch target injection (CVE-2017-5715)
• Variant 3: Rogue data cache load (CVE-2017-5754)
Spectre (Variants 1 and 2) has been shown to impact all modern chips manufactured by Intel, AMD and ARM. Meltdown (Variant 3) has been shown to impact most Intel chips since 2010, although researchers noted that with additional research and code optimization, exploitation against AMD and ARM chips may be possible.
A processor operates in two modes: kernel mode and user mode. Kernel mode is where the operating system executes, and processes running in kernel mode have access to hardware and all regions of memory. User mode is where most user processes execute. Each user mode process has a restricted view of memory, allowing access only to the process’s own virtual address space, and must use system calls to access hardware. Under normal conditions, if a user mode process attempts to directly access a memory section outside its own virtual address space, an exception will be generated which will cause the process’s thread to terminate.
While kernel memory cannot be read directly from user space without utilizing a system call, most modern operating systems still map kernel addresses into userspace processes to optimize performance. Although this sounds like a vulnerability on its own, a userspace process attempting to access kernel space outside of a normal system call will generate an exception and cause the process’s thread to terminate. This means that although kernel space is mapped into the user process address space, it is effectively inaccessible to the user space process outside of normal system calls.
Meltdown exploits the fact that kernel space memory is mapped into the user space process’s address space and the fact that, to optimize performance, most modern processors execute instructions out of order, to bypass the normal protection mechanisms and allow unprivileged user space processes to access kernel space memory. By executing specially crafted out of order instructions, kernel space memory address can be written to the process’s address space, which can then be retrieved via an address reference in the processor’s cache. Although this unprivileged memory access ultimately causes an exception which causes the rest of the out of order instructions to be discarded, the retrieved memory sections continue to reside in the user process’s unmapped memory space, and the reference still remains in the processors’ cache.
Although Address Space Layout Randomization (ASLR) means that an attacker will not know the location of kernel space memory beforehand, this presents more of a stumbling block than a barrier for this attack. The researchers who discovered Meltdown found that the location of kernel memory can be determined in about 128 guesses on a system containing 8GBs of memory, making ALSR trivial in preventing this attack.
Spectre exploits another set of processor features, branch prediction, and speculative execution, to access protected memory locations. Most processes contain a vast array of branch conditions, such as If/Then/Else statements. To optimize performance, as a process executes, the processor keeps track of which branches are executed most often. This allows the processor to “think ahead”, read memory sections and snapshot pre-execution of the branch which it believes is most likely to be taken. This is referred to as speculative execution.
Spectre causes the processor to access a memory location of the attacker’s choosing within the user process’s space during branch prediction and speculative execution which would not be accessed during normal process execution. Although these memory locations are never actually executed by the processor, they now exist in the processor’s cache and can then be read by the attacker.
Patches and Workarounds
There are patches currently available for the Linux kernel to prevent the Meltdown attack. Known as KAISER or Kernel Page Table Isolation (KPTI), these patches prevent most kernel memory from being mapped into userspace processes (although some kernel memory, such as the IDT, must still be mapped to user mode address space). Microsoft has also developed a similar patch for Windows to address Meltdown; however, due to compatibility issues (BSODs) with some endpoint protection solutions, Microsoft has cautioned users to check with their endpoint protection provider prior to deploying the patch. An unofficial list of support for the Windows patch by common endpoint protection solutions is available here. It is important to note that these patches do not fix the actual vulnerability itself, they simply limit the practical exploitation of the vulnerability. Some users have also been reporting issues with the Microsoft patch, causing systems with older AMD processors to fail to boot correctly.
For users still running legacy systems, such as Windows XP and Windows Server 2003, these systems will continue to remain vulnerable to Meltdown and Spectre along with the many other vulnerabilities still present on these systems. The best protection is to harden around these systems, or even better, replace them.
Patches to address these vulnerabilities do come with some performance implications, however. Estimates range from a 5% to a 30% decrease in performance depending on system usage. Systems utilized for more common tasks, such as email, Internet browsing, and word processing, are less likely to see a major performance impact from these patches. However, systems used for tasks which require more intensive hardware utilization are more likely to suffer a noticeable impact.
Apple, which bases its iOS A-series processors on ARM’s instruction set, has already deployed patches for some devices and plans to release patches for other devices soon. Apple has advised users are to check for new updates for their devices and check to ensure that they are running the most current operating system for their devices.
Google says that Android devices, which also most commonly run on ARM processors, should be protected if they have the latest security update installed. Currently, Android devices are protected by restricting access to the high precision timers needed to determine if a cache hit or miss has occurred; however future Android security updates will also include additional mitigations based on KPTI. Users of Google Android devices, such as the Nexus and Pixel, should have immediate access to the security updates. Users of other Android devices will likely have to wait a little longer for these patches as they are tested and pushed through each manufacturer’s update process.
Chromebook users running the latest version of Chrome OS (version 63 as of now) should already be protected against these vulnerabilities as well. To check if a Chromebook is updated to version 63, or if an update is available, users should check Google’s list of Chrome OS devices.
Qualcomm processors are affected by these vulnerabilities as well, although patches have not yet been released for all systems running on Qualcomm processors. Users are advised to check for operating system updates, particularly when running Android and Linux, on their Qualcomm-powered devices. IBM firmware updates should be available in the upcoming weeks for their Power CPUs to address Spectre-like issues in its design.
Cisco is also preparing to release patches to prevent exploitation of these vulnerabilities. Since most Cisco products are closed systems, which do not allow customers to run custom code on the device, practical exploitation of these vulnerabilities on Cisco devices is limited. However, certain processor and OS combinations in some Cisco products could leave them vulnerable, and it is recommended that users patch their Cisco devices as soon as a patch is available.
What does this mean for me?
While Meltdown and Spectre do pose some serious potential security risks, at the moment there is no need to panic. Users are still far more likely to be exploited via a phishing email than either of these vulnerabilities. So far, there has been no evidence that either of these attacks has been used in the wild, although it is certainly possible that others have known about these vulnerabilities for some time. It will likely take some additional time and effort to advance these attacks from a proof of concept to a reliable attack vector.
There has been enough attention given to these vulnerabilities that most major operating systems and applications already have patches available or will have patches available soon. Patching will be the best defense against these attacks. With proper patching, the risks from these vulnerabilities will be significantly reduced or eliminated. Users of less common or no longer maintained software which may be vulnerable to Spectre Variant 1 should check with their software vendors or deploy additional protections around these systems. Legacy and embedded devices, with limited or no ability to patch, will likely see the greatest long-term risk associated with these attacks.
The greatest potential impact from Meltdown could have been on cloud service providers, as they could have allowed both access to the hypervisor as well as data from other instances. However, most of the major cloud service providers were notified of the vulnerability prior to public disclosure and should have patches already deployed, or being deployed soon. Cloud service users should check with their individual providers to determine their potential existing exposure from these vulnerabilities.
The most significant lasting impact from Meltdown and Spectre may be these types of hardware vulnerabilities exist in the first place. Although these vulnerabilities have been present in hardware for many years, little attention has been paid to this class of vulnerabilities. Hardware vulnerabilities such as these present a very attractive vector for attackers due to the high level of access they provide and the potential for VM escape; even more so when they can be exploited remotely. We have seen this type of vulnerability “gold rush” in the past, where the discovery of a single vulnerability leads to increase in scrutiny of a certain application or system, disclosing dozens of additional vulnerabilities. Given the challenges in detecting, investigating and patching these types of hardware vulnerabilities, a gold rush here could have serious security implications.