It Never Ends: Two More Intel CPU Vulnerabilities Disclosed
The list of security vulnerabilities due to hardware flaws in Intel processor products is very long and it just got longer. Intel has issued a "Data Leakage Advisory" where they admit two additional locally exploitable vulnerabilities which could be used to get secret information from processes running on a computer.
written by 권유리 (Kwon Yu-ri) 2020-01-28 - last edited 2020-02-04. © CC BY
Before you panic: All the Intel processor vulnerabilities like Meltdown, Spectre, Zombieload, Foreshadow as well as the very similar security holes in the GPU part of Intel processors with integrated graphics allow one process to get information from another using side-channel and/or timing attacks. An attacker will, put simply, have to be able to run code on the machine to steal data from it. This is a major problem for cloud providers who offer virtual machines on shared systems to everyone willing to pay a dime or less for an account. It is mostly a non-issue for the vast majority of desktop and laptop users.
Intel published a Processors Data Leakage Advisory (INTEL-SA-00329) on January 27th where they admit to two kind of not new security holes in their processors.
Vector Register Sampling[edit]
Intel describes CVE-2020-0548, or "Vector Register Sampling", as:
"CVE-2020-0548 is an information disclosure vulnerability with a CVSS score of 2.8, low, referred to as Vector Register Sampling. This issue is rated “low” as the user would first need to be authenticated on the target system, the high complexity of an attack, and low confidence in the attacker’s ability to target and retrieve relevant data."
Vector Register Sampling, could affect GNU/Linux users. Active kernel mitigations for this attack are currently not indicated in the current kernel documentation, code or mailing list. The advisory makes it sound like it is a mostly theoretical hard to actually exploit vulnerability so it is probably nothing to worry too much about. The kernel developers will likely add a mitigation if they deem it to be serious enough to warrant making the Linux kernel run even slower on Intel processors.
CacheOut aka "L1D Eviction Sampling"[edit]
L1D eviction sampling allows an attacker with a regular user account on a system to get sensitive data from the kernel, other virtual machines on the same system, other processes on the same system, "security card extensions" (SGX) and so on. It works across security domains. It is a pretty big deal for cloud providers.
Intel describes CVE-2020-0549 aka "CacheOut" and "L1D Eviction Sampling", as:
"CVE-2020-0549 is also an information disclosure vulnerability requiring authenticated local access. The CVSS score is 6.5, medium. Referred to as L1D Eviction Sampling, the severity score is higher on this one because the attack complexity is lower and the ability to target specific data higher. This vulnerability has little to no impact in virtual environments that have applied L1 Terminal Fault mitigations."
The L1 Terminal Fault mitigations Intel refer to have been available in Linux kernels since August 2018. They can be controlled by the l1tf= kernel parameter (described in the Linux kernels Documentation/admin-guide/kernel-parameters.txt file).
l1tf defaults to l1tf=flush. The kernel documentation describes that option as:
"Leaves SMT enabled and enables the default hypervisor mitigation, i.e. conditional L1D flush.
SMT control and L1D flush control via the sysfs interface is still possible after boot. Hypervisors will issue a warning when the first VM is started in a potentially insecure configuration, i.e. SMT enabled or L1D flush disabled."
kernel-parameters.txtThose who want total l1tf protection have to turn SMT/hyperthreading off. The l1tf=full option does this:
"Provides all available mitigations for the L1TF vulnerability. Disables SMT and enables all mitigations in the hypervisors, i.e. unconditional L1D flush.
SMT control and L1D flush control via the sysfs interface is still possible after boot. Hypervisors will issue a warning when the first VM is started in a potentially insecure configuration, i.e. SMT enabled or L1D flush disabled."
kernel-parameters.txtTurning Hyperthreading/SMT off has a huge performance impact and the sum of the performance penalties from all the mitigations for the now really long list of vulnerabilities in Intel processors is adding up. Those who are daring and brave can use the kernel parameter mitigations=off to avoid any performance penalties by leaving all the security holes wide open.
A dedicated website setup just for the "CacheOut Attack" describes the attack as requiring the Transactional Synchronization Extensions (TSX) found on Intel processors. These instructions were introduced with the Haswell architecture in 2013. The Linux Kernel has had a tsx command line argument which defaults to tsx=off since November 2019. It is only effective on processors released after Q4 2018, processors released before that do not have any support for turning the TSX feature off using software calls. Intel plans to release a microcode firmware update for older processors which disables TSX with no OS support for turning it back on again. TSX was disabled on Haswell, Haswell-E, Haswell-EP and early Broadwell processors with a microcode update in 2014 because the implementation in those processors were flawed in unrelated ways.
CVE-2020-0549, aka CacheOut and "L1D Eviction Sampling", should have little impact on most GNU/Linux users. Everyone who is running a kernel which is less than a year old are either using the default l1tf=flush mitigation or intentionally using a kernel parameter like mitigations=off. Those running data-center services with virtual machines used by a variety of customers may want to use l1tf=full. A Intel memory titled "L1D Eviction Sampling" notes that:
"As the list of processors affected by L1D eviction sampling are a subset of those affected by L1TF, systems affected by L1D eviction sampling may run software that already applies L1TF mitigations. Fully applying the L1TF mitigations for virtual machine managers (VMMs) ensures that the sensitive memory contents of the VMM or other virtual machines (VMs) will not be in the L1D cache when a possibly malicious VM executes. This helps prevent the malicious VM from attacking a VMM with L1D eviction sampling."
Published January 27th, 2020
You may want to use l1tf=full on your desktop or laptop too if you feel there is a risk that you will get specially crafted malware which uses CacheOut to get sensitive data. The performance penalty if disabling SMT/hyperthreading, which is something that option does, is very noticeable so it may not be worth it. There is, of course, mitigations=off for those who want maximum risk and performance.
You can read the CacheOut research paper here.
CPU without vulnerabilities[edit]
A CPU without vulnerabilities, however, is to be found at Gigatron.io
Enable comment auto-refresher