Apply firmware updates provided by system vendors. Updates may specifically refer to UEFI, BIOS, microcode, ucode, or individual hardware device firmware. Multiple separate firmware updates may be available for a given system, or all updates may be rolled up into a single package (no universal standard exists). Firmware updates may not be delivered through established patching services such as Windows Update and are easy to miss. Consult vendor resources such as those provided by Dell and HP.

Ensure that firmware updates are allowed to execute uninterrupted. Firmware updates may have multiple phases. For example, firmware updates for Intel platforms typically have a distinct phase for updating the Management Engine (ME) that follows platform firmware update. Reboots may exist between phases.

Microsoft, Apple, Red Hat, and Google have all released patches for their respective operating systems. Some software vendors – particularly web browsers, document readers, and development kits – may also have side-channel attack mitigation updates. Apply all patches to software. Be sure to check software that use vendor-specific update services or patch files – not all vendors provide patches for operating system vendors to utilize.

VMware, Citrix, Xen Project, Amazon, Microsoft, and other virtualization and cloud providers have also provided side-channel attack mitigation patches. Some infrastructures require system administrators to apply patches, and others – typically cloud infrastructures – automatically apply patches without any input.

Some OS vendors have released patches with disabled mitigations due to performance impact concerns. Perform a risk analysis to determine the infrastructure’s exposure to arbitrary executable and script execution. Apply mitigations to endpoints most exposed and at risk. Check to ensure Spectre, Meltdown, MDS, and other mitigations are actually enforced. Application and script whitelisting combined with endpoint permissions lockdown may be sufficient alternatives to performance-impacting mitigations.

Some updates may require configuration changes to enable the full benefit of side-channel attack mitigations. Development kits in particular may require re-compilation of binaries to enable new CPU instructions. Operating systems may need changes made to user and network policies. Consult vendor resources for guidance on applying the appropriate mitigations for your use case.

Disable Hyper-Threading on systems that match ALL of the following requirements:

1. Intel systems handling sensitive information (e.g. classified, financial, medical)
2. Intel systems that allow the execution of arbitrary programs and scripts (e.g. systems lacking application whitelisting)
3. Intel systems that are part of the 9th generation or older

All form factors are affected (e.g. desktops, servers, notebooks, tablets). Disabling Hyper-Threading may impart a significant performance penalty on some use cases. Virtual processor and Simultaneous MultiThreading (SMT) solutions from vendors other than Intel are not implicated as susceptible to MDS as of March, 2020.

Spectre exploits performance-enhancing behaviors known as “speculative execution.” Variants include SpectreNG, SpectreRSB, Spectre Prime, and Spectre followed by version numbers. Technical names include bounds check bypass, write bounds bypass, protected memory range bypass, enclave branch target injection, return stack poisoning, and network cache shadow copy.

During speculative execution a processor may continue executing down one branch of a conditional instruction rather than waiting for the result. All execution following the conditional is referred to as “speculation” since the processor does not yet know the result of conditional instruction that has not yet returned a result. Once the result is returned, the processor’s guess is either determined to be correct or incorrect. A correct guess shields the user from any performance impact, delay, or lag. Incorrect speculation temporarily pollute’s the processor’s cache with data that should not be present and may be available for exfiltration. Alternatively, observation of processor energy use, register use, executed instructions, speed variation, and other electronic indicators can reveal secrets without needing to read cache.

For an example, assume there exists a local application that presents the user with a login prompt. Upon successful login, a secret message is displayed. An attacker can attempt to exploit Spectre vulnerabilities by deliberately entering incorrect logins and reading processor cache. The processor may speculatively load the secret message in anticipation of a correct login. The attacker can then fish the secret message out of cache despite not having login credentials to see it.

Meltdown builds upon Spectre. Variants include Meltdown Prime, Total Meltdown, and Meltdown followed by version numbers. Technical names include branch target injection, rogue data cache load, and rogue register load. Meltdown exploits a weakness in permission-checking during speculative execution. Some processor implementations will execute instructions prior to checking for permissions to access restricted regions of memory. Secrets can be leaked, security boundaries can be bypassed, and even virtual separation can be defeated due to the permission check that happens after speculative execution has already loaded protected data.

For an example, assume there exists a local application that features multiple services. Some of the services require the user to have administrative credentials. An attacker could launch the application, deliberately try to use a service they don’t have permission to utilize, and then recover speculative execution cache data resulting from the processor’s possible assumption that the user had the correct permissions. If the application happened to be a user management system, then the attacker may have the opportunity to siphon administrative credentials out of cache.

Foreshadow builds upon Spectre. Variants include SGXpectre and technical names include L1 terminal fault and cache overrun. Foreshadow is all about violating trust boundaries – different from Meltdown’s focus on permissions and separations. Regions of memory can be tagged to have separations enforced at the hardware level. Secure enclaves, such as Intel’s SGX, share system RAM with other applications and operating systems. Hypervisors, also known as Virtual Machine Managers (VMMs), can leverage different hardware virtualization features to separate their memory from other applications and operating systems too. Foreshadow allows a process running as a user to violate the boundaries between user memory and SGX or VMM memory via speculative execution.

For an example, assume there exists a local SGX application – effectively a black box from some trusted vendor – that contains a decryption key. A malicious user could leverage a Foreshadow exploit to leak the decryption key out of the SGX-protected enclave. SGX enclaves typically run as user processors meaning that no elevated credentials are necessary.

BranchScope builds upon Spectre. BranchScope targets the Branch Prediction Units (BPUs) that handle speculation when branching instructions, such as a conditional, are encountered. Modern processors handle multiple process threads simultaneously. BranchScope leverages processes against each other to influence and sometimes control the flow of speculative execution. Processes may prime the Branch Predictor itself to be predisposed to a specific solution, or they may corrupt the state of BPUs.

For an example, assume there exists a local application that has a login prompt and displays a different secret message based on which user has logged in. An attacker utilizing BranchScope could convince the processor to speculatively load the secret message for a specific user even though the attacker does not have their password.

TLBleed is a Spectre-like vulnerability that can exist in some poorly-developed software. TLBleed requires a processor that feeds multiple execution threads to a single processing core. Intel brands this technology Hyper Threading, and AMD uses the term Simultaneous Multi-Threading (SMT).

One thread acts as the victim and the other acts as the attacker. The attacker can observe the victim thread’s activity by accessing memory addresses in the shared-core’s Transaction Lookaside Buffer (TLB). TLB entries can be used to translate between virtual and physical memory locations. The attacker can observe any memory the victim has been using including memory used to store prime numbers for cryptographic operations. Processor vendors view the fault as a problem with obsolete third-party development libraries that are not thread-safe. As a result, no CVE has been issued.

PortSmash is similar to TLBleed. However, the attack thread observes the timing, cache accesses, memory accesses, energy use, and behavior of the victim thread. The attack thread does not need to access memory via the TLB. Close observation of the processor and platform hosting the victim thread can allow the attack thread to leak data from the victim thread. PortSmash is particularly effective against cryptographic functions where entropy can be observed or stealthily mirrored.

NetSpectre is the only side-channel vulnerability listed on this page that does not require local code execution on a target system. Attackers can target systems connected to a network and flood them with data – particularly data that takes advantage of AVX instruction sets. Processing of that data can reveal electronic indicators that allow the leaking or duplication of system secrets. NetSpectre is a noisy and slow attack method due to the large amount of data that must be sent to the target machine. An exploitable network driver, network service, or network application, such as a web browser, is also required on the target machine.

Microarchitectural Data Sampling (MDS) vulnerabilities are also referred to as ZombieLoad, Fallout, and Rogue In-flight Data Load (RIDL). MDS vulnerabilities expand upon weaknesses identified in Meltdown and TLBleed. Mitigations have focused on controlling access and frequently clearing processor caches. However, processor cache data is staged in buffers when transiting into and out of cache memory space. MDS exploits target the buffers. Information can be leaked from or injected into buffers to manipulate processor execution and speculative behaviors.

CacheOut expands upon MDS and RIDL vulnerabilities and targets Intel platforms. Researchers introduce new mechanisms for accessing data across all security boundaries and in the presence of recent mitigations. New microcode and kernel patches are expected in the first half of 2020 to address CacheOut vulnerabilities.

Take A Way (TAW) targets AMD platforms with a new class of side-channel vulnerabilities. TAW involves manipulating power management features (specifically Cache Way Predictors), defeating Address Space Layout Layout Randomization (ASLR), and leveraging Spectre-like attacks to covertly access unauthorized memory. Successful attacks can be carried out via JavaScript found on a malicious website. However, the attack is slow to leak data, only captures incomplete snippets of data structures, and can readily be mitigated via software patches.

Load Value Injection (LVI) expands upon concepts introduced by Spectre, Meltdown, and MDS. LVI targets Intel platforms. Instead of leaking data through side-effects, LVI takes a more direct approach by having the CPU volunteer data as a result of carefully placed instructions that are triggered in sequence by fault and load commands. The result is a type of undetectable, covert channel that bypasses existing side-channel mitigations and violates the boundaries of security enclaves – specifically Intel SGX.

Mitigation measures involve the recompilation and redeployment of SGX-enabled applications. Speculation and control flow are also more tightly controlled post-mitigation. A significant performance penalty is expected.

LoJax is a malicious modification to the anti-theft solution known as Computrace or LoJack. Each of these applications exist as UEFI modules implanted into system firmware. Firmware does not get cleared when the operating system is reformatted or storage media is replaced. Such persistence enables anti-theft solutions to continue to function despite attempts to disable them.

Microsoft plays a prominent role in the assigning of UEFI Secure Boot signatures. Most modern machines ship with a Microsoft Windows Key Exchange Key (KEK) and a Microsoft Third-Party UEFI Marketplace KEK. Sometimes signatures are issued to bootable binaries by mistake. Rather than revoke the KEK and invalidate thousands of products, Microsoft can issue a Blacklist Database (DBX) hash for a specific signed binary.

Microsoft’s patch KB4524244 issues a DBX record for a bootloader with the ability to bypass UEFI Secure Boot Protections. Initial boot firmware begins the Secure Boot process. After the Boot Device Select (BDS) phase of UEFI boot, execution control and responsibility for Secure Boot enforcement transfers to the software environment – specifically the bootloader. The bootloader identified by Microsoft’s DBX update is known to ignore Secure Boot and break a chain of trust that should extend to Microsoft’s kernel. However, some endpoints have had difficulty applying the DBX update record which has caused Microsoft to pull back KB4524244.

To mitigate the threat of the dangerous bootloader, add the following SHA-256 hash to each system’s DBX records if it is not already present:

81d8fb4c9e2e7a8225656b4b8273b7cba4b03ef2e9eb20e0a0291624eca1ba86