## -*- mode: moinmoin -*- ## eg '== GNU C Library buffer overflow in __nss_hostname_digits_dots() (CVE-2015-0235 aka GHOST) ==' == Special Register Buffer Data Sampling (SRBDS) Hardware Vulnerability in Intel CPUs (CVE-2020-0543, aka Crosstalk) == ## Description. Should contain a high level description and optional low level description along with how the vulnerability can be exploited and the result of exploitation It was [[https://www.intel.com/content/www/us/en/security-center/advisory/INTEL-SA-00320.html | discovered]] that special register buffer data of certain Intel CPUs may be exposed to a malicious process executing on the same CPU. Particular processor operations (e.g RDRAND, RDSEED) use data from outside the physical processor core - this can be done via an internal microarchitectural operation called a special register read. This uses part of a shared staging buffer which may not be completely zero'd on subsequent uses by other threads. As such, a local attacker may be able to infer stale values which were previously returned from special register reads to other processors (as their contents may still be present in other parts of the shared staging buffer). Some special register reads return sensitive information (such as RDRAND, RDSEED and SGX EGETKEY) and so an attacker executing code on the same CPU may be able to infer these values for another thread / process executing on the same CPU. This attack relies on the same techniques used to exploit previous microarchitectural speculative execution vulnerabilities such as [[https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/MDS | MDS]] and [[https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/TAA_MCEPSC_i915 | TSX Asynchronous Abort]], and affects some client and Intel® Xeon® E3 processors; it does not affect other Intel Xeon or Intel Atom® processors. Mitigations for this issue are provided by CPU microcode updates via the `intel-microcode` package. This mitigation consists of ensuring data in the shared staging buffer is overwritten by the RDRAND, RDSEED and EGETKEY instructions and serialising execution of RDRAND etc instructions across multiple logical processors. As a result, this will have an effect on the performance of these instructions. In conjunction, the microcode updates also supports an opt-out mechanism so that performance can be restored if desired - to support this, the Linux kernel supports a kernel command-line option `srbds=off` to allow system administrators to make use of the opt-out mechanism. For details on the boot command line option and how to check system status, please see the [[ https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/special-register-buffer-data-sampling.html | Linux Kernel Special Register Buffer Data Sampling Admin Guide ]]. It should be noted, that for Linux, whilst RDRAND / RDSEED output is used in the generation of secure random numbers via the `/dev/urandom` device / `getrandom()` system-call, this value is also mixed with other sources of entropy in a secure manner, and knowledge of RDRAND / RDSEED values by a local attacker is highly unlikely to allow recovery of the actual random values which are then subsequently provided to applications which may use these in the generation of secret key material or other sensitive data. As such, it is highly unlikely this vulnerability will allow recovery of secret keys or similar *unless* an application is using RDRAND / RDSEED instructions directly to generate such secrets. For a full list of affected processors, please refer to [[ https://software.intel.com/security-software-guidance/insights/processors-affected-special-register-buffer-data-sampling | Intel's guidance document]]. ## Versions section should include: ## - version fixed in upstream ## - version first introduced in upstream (if applicable) ## - version fixed in Ubuntu ## - reference to the USN This issue was fixed in Intel IPU 2020.1. Ubuntu 14.04 ESM, 16.04 LTS, 18.04 LTS, 19.10 and 20.04 LTS were affected. To address the issue, ensure that the appropriate version of the `intel-microcode` package as listed below is installed. These updates were announced in [[http://usn.ubuntu.com/usn/4385-2|USN 4385-2]]. Computers that have trouble booting after installing the microcode update can bypass the microcode loading step by adding `dis_ucode_ldr` to the kernel command line in the grub bootloader. This will disable all microcode-loaded mitigations and other bugfixes, so it's best to use it temporarily, to install new microcode. || '''Release''' || '''intel-microcode Version''' || || 20.04 LTS || [[ https://launchpad.net/ubuntu/+source/intel-microcode/3.20200609.0ubuntu0.20.04.2/ | intel-microcode 3.20200609.0ubuntu0.20.04.2 ]] || || 19.10 || [[ https://launchpad.net/ubuntu/+source/intel-microcode/3.20200609.0ubuntu0.19.10.2/ | intel-microcode 3.20200609.0ubuntu0.19.10.2 ]] || || 18.04 LTS || [[ https://launchpad.net/ubuntu/+source/intel-microcode/3.20200609.0ubuntu0.18.04.1/ | intel-microcode 3.20200609.0ubuntu0.18.04.1 ]] || || 16.04 LTS || [[ https://launchpad.net/ubuntu/+source/intel-microcode/3.20200609.0ubuntu0.16.04.1/ | intel-microcode 3.20200609.0ubuntu0.16.04.1 ]] || || 14.04 ESM || intel-microcode 3.20200609.0ubuntu0.14.04.1 || || 12.04 ESM || Not available; please consult your hardware vendor's website for a BIOS update containing new microcode || ## Timeline. Should include at a minimum: ## - when Ubuntu was notified ## - when USN was issued ==== Timeline ==== * 2019 Dec 11: Notification received * 2020 Jun 09: Coordinated Release Date * 2020 Jun 09: Ubuntu publish updated `intel-microcode` packages * 2020 Jun 10: Ubuntu publish updated `intel-microcode` packages to revert the fix for Intel Skylake family (06_4EH) === References === * https://www.intel.com/content/www/us/en/security-center/advisory/INTEL-SA-00320.html * https://www.vusec.net/projects/crosstalk * https://software.intel.com/security-software-guidance/software-guidance/special-register-buffer-data-sampling * https://software.intel.com/security-software-guidance/insights/deep-dive-special-register-buffer-data-sampling * https://software.intel.com/security-software-guidance/insights/processors-affected-special-register-buffer-data-sampling * https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/special-register-buffer-data-sampling.html ---- CategoryTemplate