Meltdown and Spectre Explained
How to protect against the Meltdown and Spectre vulnerabilities
Meltdown and Spectre are two different (but related) vulnerabilities found in almost all modern processors, affecting mobile devices, desktop and laptops, and servers. They are the result of hardware architectures that allow user-space programs to read in-memory data that they wouldn't normally be allowed to read. For instance, one user's application could potentially access passwords or encryption keys from another running process.
For more discussion on Spectre and Meltdown, click on the link below to hear Gene Geddes and Ian Evans on this episode of WWT's TEC17 podcast series.
The vulnerabilities affect desktops and laptops, tablets, mobile phones, servers and cloud server instances — pretty much everything. Of particular concern are multi-tenant or shared environments such as public/private clouds where sensitive user/company/state data could potentially be accessed by bad actors.
Initially, researchers believed the only solution would be to physically replace all affected processors – an impractical solution in the short term. Instead, researchers, processor manufacturers, and leading industry software vendors agreed that operating system and application code would be patched to provide near term protection against exploits.
For more technical detail, please refer to the published security research papers on Meltdown and Spectre.
How do they affect me?
The not so bad news:
- There are no known exploits in the wild at the time of this writing. While the vulnerabilities are based on an old set of design decisions, it doesn't appear any bad actors have been exploiting the issue.
- The vulnerabilities do not appear to be remotely accessible – they are local only. In order to leverage an attack, an application needs to run locally on the machine. This could be a virtual machine reading memory contents written by another virtual machine, or possibly even malicious JavaScript loaded through a web browser. It is possible for an attacker to leverage another vulnerability remotely (like a remote script injection attack through a web server or services API) and eventually trigger Meltdown and Spectre.
- The attacks are read-only and do not allow exploits to directly modify the contents of memory.
- The whole industry has been working on this for a while, with patches either on their way or already out.
- Both attacks are highly complex and difficult to make work in a real-world environment. They are reading from a rapidly changing portion of memory, so for most data center systems, there will be an enormous amount of noise in the data.
The really bad news:
- Everything is going to have to be patched, and there are different patches for Meltdown and Spectre with differing levels of complexity.
- The plan was to announce the issues publicly on 1/9/2018 with coordinated patch releases across the major industry players, but news of the vulnerabilities leaked early, leading to confusion and a perceived delay in patch releases.
- Given the nature of the patches, there is potential for degradation of application performance after applying the patches. The severity of this degradation is dependent upon the make/model of processor (especially in regards to PCID availability), the specifics of the OS or application patches, and the type of workload in question. Performance degradation could range from 5 to 40 percent.
Meltdown and Spectre – similar, but not the same
As mentioned above, Meltdown and Spectre are related side-channel vulnerabilities but differ greatly in their scope and impact. It is important to understand their operational similarities and differences.
Meltdown
- Affects most Intel processors released since 1995. Some ARM processors are affected. AMD processors do not appear to be affected at this time
- Meltdown can be patched by vendor-provided operating system patches.
- Leaks kernel and user memory
Spectre
- Affects almost all modern processors, including GPUs, are affected
- There is no simple patch for Spectre as it results from a core computational architecture design issue. Patching Spectre in the long term may require a core redesign of existing computational architectures. In the short term, it will require the combined patching of the following: CPU microcode, OS kernels, drivers, libraries, compilers, and applications.
- Leaks only user memory (not kernel memory)
WHAT ARE THE VENDORS DOING?
Intel: Security Advisory/Newsroom/Whitepaper
ARM: Security Update
RISC-V:Blog
NVIDIA: Security Bulletin/Product Security
Microsoft: Security Guidance/Information regarding anti-virus software/Azure Blog/Windows (Client)/Windows (Server)
Amazon:Security Bulletin
Google: Project Zero Blog/Need to know
Android: Security Bulletin
Apple: Apple Support
Lenovo: Security Advisory
IBM: Blog
Dell: Knowledge Base/Knowledge Base (Server)
Huawei: Security Notice
Synology: Security Advisory
Cisco: Security Advisory
Mozilla: Security Blog
Red Hat: Vulnerability Response/Performance Impacts
Debian: Security Tracker
Ubuntu: Knowledge Base
SUSE: Vulnerability Response
Fedora: Kernel update
Qubes: Announcement
Fortinet: Advisory
NetApp: Advisory
LLVM: Spectre (Variant #2) Patch/Review __builtin_load_no_speculate/Review llvm.nospeculateload
CERT: Vulnerability Note
MITRE: CVE-2017-5715/CVE-2017-5753/CVE-2017-5754
VMware: Security Advisory/Blog
Citrix: Security Bulletin/Security Bulletin (XenServer)
Xen: Security Advisory (XSA-254)/FAQ
This section has been updated to reflect our most recent findings. (2/16/18)
Microsoft has been very active in releasing several patches for Spectre over the past two weeks and has also released a number of free tools and monitoring options. For more on this, check out: https://blogs.windows.com/business/2018/02/13/windows-analytics-now-helps-assess-meltdown-and-spectre-protections/
One of the more interesting approaches to fighting Spectre is an effort by Microsoft to address variant #1 (bounds checking) by having its C++ compiler insert a special instruction in front of any code segment that accesses an array to prevent invalid access during speculative execution. Check out this excellent summary in Ars Techica. Unfortunately, Paul Kocher, one of the original discoverers of the Spectre vulnerability, has already tested the fix and believes it falls short of adequately blocking most Spectre-based attacks. Nevertheless, this effort is a great example of the sort of innovative research happening now that will be needed to counter Meltdown and Spectre in the long term.
Many cyber security OEMs also continue to offer their help in this battle, just two examples being Qualys and Palo Alto with new firewall signatures to detect attacks based on publicly available research code.
How can WWT help?
There are two areas of risk most organizations have regarding Meltdown and Spectre: the security risk itself, and the operational risks of patching and post-patch affects.
WWT is focusing on both and is here to help enterprise organizations make the best of a bad situation.
- Our security team is actively researching the vulnerabilities to better understand scope and scale. Some of our engineers/architects/analysts have deep knowledge of similar side-channel attacks, so we have the right people in place to assist. We plan to share any additional insight/updates via WWT Blog posts.
- Our Advanced Technology Center (ATC) and global engineering teams are building out test environments in the WWT ATC to perform before and after performance testing for common scenarios and workloads. From this we hope to be able to provide real-world baseline performance guidance that organizations can leverage to make better decisions about which systems to patch, performance expectations after patching, and how to quickly and efficiently resolve compute capacity shortages post-patch.
- For vendors and enterprise organizations that have specific applications or system builds they need to test, WWT's ATC is an ideal place to get this done quickly and safely. Vulnerability testing, patch testing, patch procedure testing, and performance testing can all be achieved in the ATC.