2018/01/09 Advisory: Spectre / Meltdown
This page covers ongoing efforts and may be updated (latest: 2018-01-18).
The beginning-of-the-year has been dominated by the security vulnerabilities known as "Meltdown" and "Spectre". "Meltdown" breaks down the boundary that separates user applications from accessing privileged system memory space. This vulnerability is confirmed to exist in all Intel processors since 1995, except for Intel Itanium and Intel Atom before 2013. This includes computers by popular vendors such as Apple, Microsoft, Dell, HP, and Lenovo. "Spectre" is similar but allows an attacker to utilize a CPU's cache channel to read arbitrary memory from a running process. Unlike Meltdown, Spectre is confirmed to affect Intel, AMD, and ARM processors. This includes computers, tablets and smartphones made by popular vendors such as Apple, Microsoft, Dell, HP, Google, and Lenovo. The relatively good news is that Spectre is much more difficult to successfully exploit as its the attack surface is limited to user space processes, e.g. web browsers, desktop applications. Also, while there are proof-of-concepts out in the wild, there has been no systematic exploitation of either Spectre or Meltdown reported yet. Still, we recommend to all users to keep their systems up-to-date using the standard (automatic) update mechanisms of their Windows, Linux, Mac, Android or iOS devices.
Please note that not taking any action is not an option as this will render your device exploitable!
Finally, this might just be the beginning. Security researchers as well as the malicious evil are now moving the focus to other, similar hardware-related vulnerabilities. Some might be published in the future and would require another iteration of applying fixes…
Please note that the nomenclature is a bit fuzzy, but of importance:
- Bounds check bypass (CVE-2017-5753), dubbed "Variant 1" or "Spectre"
- Branch target injection (CVE-2017-5715), dubbed "Variant 2" or "Spectre"
- Rogue data cache load (CVE-2017-5754), dubbed "Variant 3" or "Meltdown"
A fix to this variant depends strongly on the CPU hardware. Neither Microsoft nor RedHat provide at this very moment (2018018-12h) a fix. Instead, these fixes would need to be provisioned by the corresponding hardware vendors. CERN IT is in contact with those vendors and will publish/apply fixes once those are available.
Your Strategy for Variant 1 & 3
- For CERN CentOS7 and SLC6, fixes have been made available for testing through the CERN Linux software “test”/QA repositories. These are released to production on Thursday, January 11th, 2018. However, those fixes might not be the final ones. In any case, in order to be active, they would require a restart of the operating system. Details can be found on the CERN Status Board;
- For CERN centrally managed Windows devices, fixes are available through CMF as of Wednesday, January 10th, 2018. In order to be active, they would require a restart of the operating system;
- For Macs, please upgrade to macOS 10.13.2 (latest version of High Sierra) and make sure all available security updates are installed. A more detailed statement of Apple can be found here;
- Individual, non-CERN managed devices (private or CERN; office PCs, laptops, smart phones, …) should be updated using the standard updating mechanisms (be it CMF, Windows upgrade, yum update, …) and subsequently rebooted. We are basically at the mercy of the operating system providers to produce the relevant fixes for the right hardware (i.e. the CPU chip set). Hence, some devices might not be fixed at any moment in time. Others might need to be updated more than once, as further fixes are deployed. Hence, it is imperative that automatic updating mechanisms are enabled as part of standard good security practices. In case you us "Chrome" as your standard browers, we recommend in addition to enable site isolation;
- Virtual machines in the CERN Computer Centre can already try out the fixes which have been pushed into Puppet Q&A. Corresponding studies are on-going within CERN / CERN IT and the WCLG / HEP community. Please note that these fixes just correct for Variant 1 and 3. Variant 2 would require the underlying Hypervisors to be fixed, too (see next point);
- For Hypervisors in the CERN Computer Centre, the CERN IT Cloud Team are performing functional and performance testing of the provided fixes, and have defined a roll-out schedule. This will require all VMs to be hard-rebooted to protect themselves against Variant 2. As they would require the restart, too, a careful rebooting campaign for each availability zone is scheduled for the next weeks. The corresponding schedule and all technical details are announced on the CERN Status Board and will be updated there;
- The WLCG and the EGI are currently applying a similar strategy to all Grid nodes.
- A shell script to tell if your Linux installation is vulnerable against Variant 3: spectre-meltdown-checker.sh
- A shell script to tell if a CPU microcode update is available for your CPU: spectre-cpu-microcode-checker.sh