Mitigation in LOCKSS Systems of Recently Disclosed Microprocessor Vulnerabilities

The beginning of 2018 is marked by three industry-wide security vulnerabilities affecting major CPU architectures, in turn affecting many operating systems and devices. Commonly nicknamed "Meltdown" and "Spectre" in news reporting, these severe vulnerabilities are specifically:

• CVE-2017-5754, "rogue data cache load" (https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5754)
• CVE-2017-5753, "bounds check bypass" (https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5753)
• CVE-2017-5715, "branch target injection" (https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5715)

The "rogue data cache load" vulnerability, CVE-2017-5754, affects primarily Intel processors. The "bounds check bypass" and "branch target injection" vulnerabilities, CVE-2017-5753 and CVE-2017-5715 respectively, affect most major processor architectures, including those of Intel, AMD and ARM. All major operating systems are affected: Windows, MacOS, Linux flavors, BSD flavors, Android, and iOS, including all major Linux distributions such as CentOS, Red Hat Enterprise Linux, Debian, Ubuntu, SUSE, Arch, Mint, and more. Generally speaking, the recommended course of action is to:

• Monitor your operating system's security advisories for the initial availability of fixes and subsequent availability of updates
• Apply these updates promptly
• Reboot after updating

Updates to the Linux kernel and intel-microcode (where applicable) packages to mitigate the "rogue data cache load" vulnerability (CVE-2017-5754) are starting to become available for current and recent versions of Linux distributions. Partial fixes to address some aspects of the "bounds check bypass" (CVE-2017-5753) and "branch target injection" (CVE-2017-5715) vulnerabilities are under development, but security researchers warn that comprehensive fixes will be difficult to achieve.

Note that some operating systems have reached end of life (EOL) and will *not* be receiving critical updates, leaving them vulnerable to these and any number of prior vulnerabilities.

The most widespread operating system in the LOCKSS community is CentOS:

• CentOS 7, the most recent version, is receiving full updates and will receive critical kernel updates
• CentOS 6 no longer receives full updates as of May 10, 2017 (https://wiki.centos.org/About/Product) but will receive critical kernel updates as maintenance updates
• CentOS 5 has reached end of life on March 31, 2017 (https://lists.centos.org/pipermail/centos-announce/2017-April/022350.html) and will *not* be receiving critical kernel updates (https://lists.centos.org/pipermail/centos/2018-January/167816.html)

The general commonality of these three vulnerabilities is that the way most modern processor architectures implement speculative execution of instructions (a commonly used performance optimization) can be exploited by unprivileged malicious code to read data from memory, including privileged kernel memory. The leaked data can be arbitrary, including passwords, encryption keys, file data loaded into memory to compute checksums, etc. Worse, some of these vulnerabilities cross the guest/host barrier, meaning that data can be exfiltrated by malicious code running in one virtual machine from another another virtual machine sharing the same physical CPU in a hypervisor or cloud environment. Thanks to the JavaScript engines of Web browsers and other means, it is not difficult these days for arbitrary outside code to be running on the CPU.

A LOCKSS system running according to best practices in the LOCKSS community — dedicated server hardware running only the LOCKSS software and minimal system software — is at lesser risk because the LOCKSS software does not execute any third party code, including the Javascript found in Web content. However, the same LOCKSS system running in a virtual machine in a hypervisor or cloud environment, or the LOCKSS software running alongside other software, are as exposed to these vulnerabilities as any affected system out there. Applying all available remedies for your LOCKSS system's operating system urgently (and if a virtual machine, that of the host and the other virtual machines on the host) and pursuing other mitigation strategies (e.g. isolating the LOCKSS software from other software on the same physical CPU) should be a priority.

For any questions or concerns, please contact us.

Further resources:

• https://meltdownattack.com/
• https://en.wikipedia.org/wiki/Meltdown_(security_vulnerability)
• https://spectreattack.com/
• https://en.wikipedia.org/wiki/Spectre_(security_vulnerability)
• Technical follow-up by Google: https://security.googleblog.com/2018/01/more-details-about-mitigations-for-cpu_4.html
• Discussion by LOCKSS Chief Scientist Emeritus David Rosenthal: http://blog.dshr.org/2018/01/meltdown-spectre.html