OpenSSL Statement on the Recent Intel/AMD Downfall/Inception Vulnerabilities

Last week marked the public announcement of the Downfall vulnerability in Intel CPUs and the Inception vulnerability in AMD CPUs. Both of these are microarchitectural side-channel attacks allowing an attacker with unprivileged execution on the same physical core as a victim process to extract confidential information from that process.

This blog post provides information and advice for users of OpenSSL. Specifically, it provides information on how users of OpenSSL may be affected by these vulnerabilities, and advice for users of OpenSSL on mitigation strategies.

Downfall Attack against Intel CPUs

Firstly, it should be noted that while the Downfall vulnerability is demoed against OpenSSL, this is a highly general microarchitectural side-channel attack which can compromise the security of essentially any software and is not specific to OpenSSL (nor is it something we could mitigate with code changes). This is not a vulnerability in OpenSSL.

Affected processors

This attack affects a large number of Intel processors across multiple generations, including Skylake, Tiger Lake and those generations in between. Exact details of affected models can be confirmed on the Intel website.

Note: The table lists a number of different historic side-channel vulnerabilities; the “Gather Data Sampling” (CVE-2022-40982) column is the relevant column. “MCU” means a processor is affected and that a microcode update has been issued.

What this attack enables

If an attacker can obtain local (but unprivileged) execution on a machine with an affected CPU, and they are able to schedule that process on the same physical core as another process, and they are able to execute AVX instructions, you should assume they are able to obtain read access to any information stored within that process’s memory.

It should be stressed that this attack is entirely dependent on an adversary being able to execute code on the same physical system as a victim process; therefore, systems which only execute code installed by trusted parties are not at risk. However, virtual machines (in the absence of the mitigations advised below) are not an effective protection.

The requirement for executing on the same physical core as a victim process can be met either by OS context switching or via hyperthreading.

Because OpenSSL provides accelerated implementations of many cryptographic primitives using x86 SIMD instructions, if an attacker executes an attack using this vulnerability on a process performing cryptographic operations using OpenSSL, there is an elevated risk that the information they are able to extract will include cryptographic key material or plaintexts, as this material is likely to have been recently processed in the victim process using SIMD instructions. In other words, the risk to key material or other cryptographic material is particularly high.

However, this does not mean that other information stored in a process is not vulnerable to compromise and we would recommend that users assume that all information stored in a vulnerable process is accessible to an attacker. While there are potentially limitations to the exploitation techniques published, the qualifiers to any such limitations are sufficiently complex to be unable to make assurances in any particular area.

Recommended mitigation

The following mitigations are available:

Intel have released microcode updates for affected CPUs and the best course of action to mitigate these vulnerabilities is to deploy these microcode updates as soon as possible.
In the absence of the ability to deploy these microcode updates, an alternative mitigation is to disable the ability to use AVX instructions in any untrusted process. This will generally require an OS update; for example, a mitigation patch is now available for the Linux kernel which allows this to be configured. Disabling AVX may break applications which have been designed or compiled under the assumption that AVX is available.

It should be emphasised that a victim process does not need to execute AVX instructions to be affected. Exploitation can only be mitigated by preventing an attacker process from executing AVX instructions.

The immediate indicated mitigation action is to install the microcode updates providing mitigation for this vulnerability provided by Intel, or system firmware updates incorporating those microcode updates provided by your system vendor. Further information on how to deploy these microcode updates is available below.

The disabling of AVX should be seen as a fallback mitigation where it is not feasible to deploy these microcode or system firmware updates.

The following are not effective mitigations:

A victim process cannot render itself immune to exploitation by refraining from use of AVX instructions, or all SIMD instructions. While the Downfall vulnerability targets code which makes use of 128-bit or wider data accesses, this includes the standard x86 XSAVE instruction which OS kernels use to save and restore process context. Therefore, even if an application recompiled itself to avoid any use of any SIMD instruction whatsoever, the contents of its registers would be exposed to an attacker whenever a context switch occurs.

It may be possible to provide mitigation by scheduling untrusted processes on separate physical cores to trusted processes, however we would not recommend trying to adopt this as a mitigation strategy, as it requires users to accurately classify trusted and untrusted processes, and to correctly configure process scheduling affinity. It would be hard for users to verify that this has been configured correctly, and there is substantial risk of misconfiguration.

Tracking mitigation deployment

An OS update may provide an indication of whether your hardware is vulnerable or not, and whether updated microcode providing mitigation for the vulnerability has been loaded. These OS updates may also provide the ability to disable AVX where such microcode updates are not loaded, but this generally needs to be explicitly requested and is not enabled by default. Note that a kernel update by itself will not load the updated microcode. Information on how to configure and verify operation for Linux-based operating systems is available here.

It is advisable to use these status reporting facilities, where available, to verify correct deployment of mitigations for this vulnerability.

It can be valuable to install these OS updates even on systems which are not affected in order to get this status reporting, as this can ease confirming whether a system is affected or not.

Obtaining microcode updates

To deploy the microcode updates for affected processors provided by Intel, there are two options:

Install a system firmware update which incorporates these microcode updates provided by your system vendor. These updates will automatically deploy the microcode update at boot time. This is the preferred option.
Alternatively, if a firmware update is not available from your system vendor, you can install the Intel microcode update yourself using the procedures specific to your OS. Note that microcode updates need to be applied on every boot.

Note also that it is generally advised to apply microcode updates as early as possible in the boot process.

You can confirm correct deployment of microcode using the mitigation status reporting mechanism provided by your (updated) OS, if your OS provides one, as discussed above.

Alternatively, you can verify the reported running microcode version numbers directly where your OS provides facilities to do so. Refer to the Intel bulletin for patched microcode version numbers.

Inception Attack against AMD CPUs

Although announced at the same time as the Downfall attack, this attack is a separate microarchitectural side-channel attack which is unrelated to Downfall and does not rely on AVX functionality.

This attack affects Zen 1, 2, 3 and 4.

What this attack enables

Similarly to the Downfall attack, successful exploitation of this vulnerability requires an attacker have local (though unprivileged) execution on an affected CPU. If an attacker is able to obtain local unprivileged execution on an affected system, you should assume they are able to obtain read access to any information stored in memory. For example, the attack can be used to obtain information stored in the kernel, or in other processes, or file contents cached in memory by the kernel.

Recommended mitigation

An OS update is always required (and always sufficient) to fully mitigate this vulnerability.

The immediate indicated mitigation action is to install the updates providing mitigation for this vulnerability provided by your OS vendor as soon as they become available.

Microcode updates

AMD has also released microcode updates for Zen 3 and 4. Installing these updates is not essential to effective mitigation of this vulnerability, as OS updates alone are capable of adequate mitigation. However, installing these updates may improve performance when mitigations for this vulnerability are enabled. In any case, installation of these updates is recommended.

These microcode updates are not needed for Zen 1 and 2.

Installing microcode updates alone does not provide adequate mitigation.

To reiterate, the indicated mitigation actions are as follows:

Zen 1 and Zen 2: Install OS updates.
Zen 3 and Zen 4: Install OS updates. If possible, deploy microcode updates (see below), though this is not required for full mitigation.

Tracking mitigation deployment

Once an OS update is installed, the update may be able to provide an indication of whether your hardware is vulnerable or not and, if so, whether mitigations are in place. Information on how to configure and verify operation for Linux-based operating systems is available here.

It is advisable to use these status reporting facilities, where available, to verify correct deployment of mitigations for this vulnerability.

For Linux, the “safe RET” and “IBPB” mitigation levels correspond to full mitigation of this vulnerability. All other mitigation levels provide only partial protection. The string “no microcode” will also appear in the status string if a microcode update is desirable but not present.

It can be valuable to install these OS updates even on systems which are not affected in order to get this status reporting, as this can ease confirming whether a system is affected or not.

Obtaining microcode updates for Zen 3 and 4

To deploy the microcode updates for Zen 3 and 4 provided by AMD, there are two options:

Install a system firmware update which incorporates these microcode updates provided by your system vendor. These updates will automatically deploy the microcode update at boot time. This is the preferred option.
Alternatively, if a firmware update is not available from your system vendor, you can install the AMD microcode update yourself using the procedures specific to your OS. Note that microcode updates need to be applied on every boot.

Note also that it is generally advised to apply microcode updates as early as possible in the boot process.

You can confirm correct deployment of microcode using the mitigation status reporting mechanism provided by your (updated) OS, if your OS provides one, as discussed above.

Alternatively, you can verify the reported running microcode version numbers directly where your OS provides facilities to do so. Refer to the AMD bulletin for patched microcode version numbers.