Researchers from ETH Zurich have discovered Branch Privilege Injection, a bug in hardware prediction-domain isolation whereby an attacker can cause predictions to be tagged with the wrong mode/privilege, and then use the incorrectly-tagged predictions to mount traditional Spectre-v2 attacks.
For more details, see: https://comsec.ethz.ch/bprc https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-01247.html
Intel are releasing microcode to address as part of IPU 2025.2. There are no software mitigations available.
https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/releases/tag/microcode-20250512
~Andrew, on behalf of the Xen Security Team.
On Tue, Feb 04, 2025 at 11:10:28AM +0100, Solar Designer wrote: On Wed, Jan 22, 2025 at 07:52:48AM -0800, Tavis Ormandy wrote: On Tue, Jan 21, 2025 at 11:38:16PM -0500, Demi Marie Obenour wrote: On Tue, Jan 21, 2025 at 06:31:31PM -0800, Tavis Ormandy wrote: It looks like an OEM leaked the patch for a major upcoming CPU vulnerability, i.e. "AMD Microcode Signature Verification Vulnerability":
https://rog.asus.com/motherboards/rog-strix/rog-strix-x870-i-gaming-wifi/helpdeskbios/
I'm not thrilled about this - the patch is not currently in linux-firmware, so this is the only publicly available patch. Tavis also posted a screenshot to Twitter at the time, from which it could be seen that ASUS had indeed listed a relevant change in there. That mention was deleted from the web page within a day or so. However, other people are discussing how to extract them:
https://winraid.level1techs.com/t/offer-intel-amd-via-cpu-microcode-archives-1995-present/102857/53 Is this fix effective, or can it be bypassed via a downgrade attack? I'm not sure yet, the vendor has been really excruciating to deal with, this is the first time I've been allowed to see the patch!! :( Much of the info is finally public (with more planned for March):
https://github.com/google/security-research/security/advisories/GHSA-4xq7-4mgh-gp6w
Google notified AMD of this vulnerability on September 25, 2024. AMD subsequently provided an embargoed fix to its customers on December 17, 2024. To coordinate with AMD, we made a one-off exception to our standard vulnerability disclosure policy and delayed public disclosure until today, February 3, 2025. This joint disclosure occurs 46 days after AMD shared the fix with its customers and 131 days after Google's initial report. Due to the deep supply chain, sequence and coordination required to fix this issue, we will not be sharing full details at this time in order to give users time to re-establish trust on their confidential-compute workloads. We will share additional details and tools on March 5, 2025.
CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:N CVE-2024-56161 As mentioned in a Xen Security Notice in here earlier today:
https://www.openwall.com/lists/oss-security/2025/03/05/3
the Google team did in fact "share additional details and tools" now:
https://bughunters.google.com/blog/5424842357473280/zen-and-the-art-of-microcode-hacking https://github.com/google/security-research/tree/master/pocs/cpus/entrysign/zentool https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7033.html
This is an exciting read with a lot of detail, but for this posting I'll focus on what the vulnerability and its fix are: The root cause of the EntrySign vulnerability is that the AMD Zen microcode signature verification algorithm uses the CMAC function as a hash function; however, CMAC is a message authentication code and does not necessarily provide the same security guarantees as a cryptographic hash function.
The weakness of using CMAC as a hash function is that anyone who has the encryption key is able to observe the intermediate values of the encryption and calculate a way to "correct" the difference so that the final output remains the same, even if the inputs are completely different.
Secure hash functions are designed in such a way that there is no secret key, and there is no way to use knowledge of the intermediate state in order to generate a collision. However, CMAC was not designed as a hash function, and therefore it is a weak hash function against an adversary who has the key. Remember that every AMD Zen CPU has to have the same AES-CMAC key in order to successfully calculate the hash of the AMD public key and the microcode patch contents. Therefore, the key only needs to be revealed from a single CPU in order to compromise all other CPUs using the same key. This opens up the potential for hardware attacks (e.g., reading the key from ROM with a scanning electron microscope), side-channel attacks (e.g., using Correlation Power Analysis to leak the key during validation), or other software or hardware attacks that can somehow reveal the key. In summary, it is a safe assumption that such a key will not remain secret forever.
Forging On We noticed that the key from an old Zen 1 CPU was the example key of the NIST SP 800-38B publication (Appendix D.1 2b7e1516 28aed2a6 abf71588 09cf4f3c) and was reused until at least Zen 4 CPUs. Using this key we could break the two usages of AES-CMAC: the RSA public key and the microcode patch contents. We were able to forge new public keys which generated the same hash as the authentic AMD key. Additionally, we calculated collisions for signatures, and were able to generate a microcode patch that shares the same signature as another message that was legitimately signed.
Vulnerability Mitigation The fix released by AMD modifies the microcode validation routine to use a custom secure hash function. This is paired with an AMD Secure Processor update which ensures the patch validation routine is updated before the x86 cores can attempt to install a tampered microcode patch. We plan to provide additional details in the upcoming months on how we reverse engineered the microcode update process, which led to us identifying the validation algorithms, extracting the CMAC key, and discovering some file format details. Alexander
Name of the issue: Redundant Prefix Issue
Description of the issue Under certain microarchitectural conditions, Intel has identified cases where execution of an instruction (REP MOVSB) encoded with a redundant REX prefix may result in unpredictable system behavior resulting in a system crash/hang, or, in some limited scenarios, may allow escalation of privilege from CPL3 to CPL0. This Redundant Prefix Issue is assigned CVE-2023-23583 with a CVSS Base Score of 8.8 High CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H.
Mitigation Intel is providing a microcode update to mitigate this issue: https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/releases/tag/microcode-20231114
Improper access control in some 3rd Generation Intel(R) Xeon(R) Scalable processors may allow a privileged user to potentially enable information disclosure via local access.
hw: Vector Register Data Sampling (CVE-2020-0548) hw: L1D Cache Eviction Sampling (CVE-2020-0549) hw: Special Register Buffer Data Sampling (SRBDS) (CVE-2020-0543) hw: Information disclosure issue in Intel SGX via RAPL interface (CVE-2020-8695) hw: Vector Register Leakage-Active (CVE-2020-8696) hw: Fast forward store predictor (CVE-2020-8698) hw: vt-d related privilege escalation (CVE-2020-24489) hw: improper isolation of shared resources in some Intel Processors (CVE-2020-24511) hw: observable timing discrepancy in some Intel Processors (CVE-2020-24512)For more details about the security issue(s), including the impact, a CVSSscore, acknowledgments, and other related information, refer to the CVEpage(s) listed in the References section.
Certain optimizations on some Intel processors target “trivial data value” cache-lines, such as all-zero value cache-lines. Such optimizations may lead to changes in cache-allocation or write-back behavior for such cache-lines. It may be possible for a local attacker to distinguish some cases of trivial-data-cache-lines from non-trivial-data cache-lines by inferring cache state using cache timing methods.
Improper isolation of shared resources in some Intel(R) Processors may allow an authenticated user to potentially enable information disclosure via local access.
A flaw was found in the CPU microarchitecture where a local attacker is able to abuse a timing issue which may allow them to infer internal architectural state from previous executions on the CPU.
A flaw was found in the implementation of Intel Advanced Vector Extensions (AVX) where a local authenticated attacker with the ability to execute AVX instructions is able to gather AVX register state from previous AVX executions.
This could allow information disclosure of AVX register state.
The microcodectl packages provide microcode updates for Intel.Security Fix(es): hw: vt-d related privilege escalation (CVE-2020-24489) hw: improper isolation of shared resources in some Intel Processors (CVE-2020-24511) hw: observable timing discrepancy in some Intel Processors (CVE-2020-24512) hw: information disclosure on some Intel Atom processors (CVE-2020-24513) Bug Fix(es) and Enhancement(s): Update Intel CPU microcode to microcode-20210525 release Do not use "grep -q" in a pipe in checkcaveats.
Certain optimizations on some Intel processors target “trivial data value” cache-lines, such as all-zero value cache-lines. Such optimizations may lead to changes in cache-allocation or write-back behavior for such cache-lines. It may be possible for a local attacker to distinguish some cases of trivial-data-cache-lines from non-trivial-data cache-lines by inferring cache state using cache timing methods.
Improper isolation of shared resources in some Intel(R) Processors may allow an authenticated user to potentially enable information disclosure via local access.
The microcodectl packages provide microcode updates for Intel.Security Fix(es): hw: vt-d related privilege escalation (CVE-2020-24489) hw: improper isolation of shared resources in some Intel Processors (CVE-2020-24511) hw: observable timing discrepancy in some Intel Processors (CVE-2020-24512) hw: information disclosure on some Intel Atom processors (CVE-2020-24513) Bug Fix(es) and Enhancement(s): Update Intel CPU microcode to microcode-20210525 release
Certain optimizations on some Intel processors target “trivial data value” cache-lines, such as all-zero value cache-lines. Such optimizations may lead to changes in cache-allocation or write-back behavior for such cache-lines. It may be possible for a local attacker to distinguish some cases of trivial-data-cache-lines from non-trivial-data cache-lines by inferring cache state using cache timing methods.
Improper isolation of shared resources in some Intel(R) Processors may allow an authenticated user to potentially enable information disclosure via local access.
The microcodectl packages provide microcode updates for Intel and AMDprocessors.Bug Fix(es) and Enhancement(s): Update Intel CPU microcode to microcode-20210216 release. (BZ#1907918)
A flaw was found in the implementation of Intel Advanced Vector Extensions (AVX) where a local authenticated attacker with the ability to execute AVX instructions is able to gather AVX register state from previous AVX executions.
This could allow information disclosure of AVX register state.
It was discovered that microprocessors utilizing speculative execution and branch prediction may allow unauthorized memory reads via sidechannel attacks. This flaw is known as Spectre. A local attacker could use this to expose sensitive information, including kernel memory. (CVE-2017-5715) This update provides the microcode updates required for the corresponding Linux kernel updates.
The microcodectl packages provide microcode updates for Intel and AMD processors.Security Fix(es): An industry-wide issue was found in the way many modern microprocessor designs have implemented speculative execution of instructions (a commonly used performance optimization). There are three primary variants of the issue which differ in the way the speculative execution can be exploited. Variant CVE-2017-5715 triggers the speculative execution by utilizing branch target injection. It relies on the presence of a precisely-defined instruction sequence in the privileged code as well as the fact that memory accesses may cause allocation into the microprocessor's data cache even for speculatively executed instructions that never actually commit (retire). As a result, an unprivileged attacker could use this flaw to cross the syscall and guest/host boundaries and read privileged memory by conducting targeted cache side-channel attacks. (CVE-2017-5715) Note: This is the microcode counterpart of the CVE-2017-5715 kernel mitigation.Red Hat would like to thank Google Project Zero for reporting this issue.