Security vs Performance Discussion with the Return of “Spectre” Vulnerability

Introduction

In January 2018, the world became aware of new vulnerabilities allowing attackers to exploit common industry-wide performance optimizations of modern microprocessors (aka chips). Almost every kind of computing device was affected - from servers, workstations, laptops, tablets, smartphones, and other gadgets. As such, “Meltdown” and “Spectre” vulnerabilities disclosed by Google Project Zero researchers, had a significant impact across the industry and consumers. ENISA has released a Cybersecurity Info Note describing these vulnerabilities and presenting recommendations - Meltdown and Spectre: Critical processor vulnerabilities.

Now, Microsoft and Google researchers have disclosed Variant 4, dubbed “Speculative Store Bypass”, which is a variant similar to “Spectre” that takes advantage of speculative execution in modern microprocessors. It can be used to potentially expose sensitive data such as passwords and encryption keys, through a side channel. Besides Variant 4, Google and Microsoft researchers have also discovered Variant 3A, dubbed "Rogue System Register Read," a variation of Meltdown that allows attackers with local access to a system to utilize side-channel analysis and read sensitive data and other system parameters. Variant 4 comes weeks after German computer magazine “c’t” (Heise) reported about a set of eight Spectre-class vulnerabilities in Intel and a small number of ARM and AMD processors.

Contextual Information

The recent disclosure of “Spectre” new variant, notably done in a responsible and coordinated way, reached the news media headlines this week. The coordinated action from the industry to the disclosure was quite efficient, with most manufacturers issuing patches in tandem to fix the problem.

The table below provides a summary of “Spectre” and “Meltdown” variants CVEs:

 Speculative Store Bypass, a Performance Feature

Speculative store bypass (SSB), a performance feature widely used by microprocessor manufacturers, relates to a category of speculation primitive referred as memory access misprediction. SSB allows a potentially dependent load instruction to be speculatively executed ahead of an older store. Specifically, if a load (read) is predicted as not being dependent on a prior store (write), then the load can be speculatively executed before the store.

The data upon which the processor is operating are commonly stored in larger and slower banks of external memory chips known as DRAM - Dynamic Random Access Memory. To quickly access this external memory, the microprocessor uses internal buffers containing copies of loads and stores. In the process of updating the memory with a new value, the update is first stored to a temporary buffer (faster memory known as CAM or Content Addressable Memory) inside the chip. The data is eventually stored back to the DRAM without interrupting the processor work.

Searching these buffers for all possible overlapping addresses still takes time. Rather than waiting for the search to end, many modern microprocessors implement a SSB that assumes no such update is present in the store buffer. Then speculatively, the processor executes the program instructions while performing the store buffer search in parallel.

Security Implications

The continuing use of this technique by manufacturers led to serious exposure of sensitive data upon shared resources such as the high-performance cache memories. In Variant 4, researchers identified that, when cache side-channel analysis is applied to store buffer speculation, it is possible to leak earlier values of certain memory locations. While the industry continues to assess the risk of SSB as low - after taking all the necessary mitigation actions (“Spectre” variant 1 mitigation is also applicable to SSB) - researchers are encouraged to evaluate further the true risk and disclose any exploitable instances that may exist.

The Mitigation Controversy

According to Intel - one of affected manufacturers - a fix was designed to be off-by-default, providing users and OEM vendors the choice to enable it. The proposed mitigation was subject to criticism by the Information Security Community for not enabling the fix by default. Users are also complaining about the serious performance impact of ca. 2 to 8 percent caused by the activation of the fix.

The option to leave the fix off-by-default for Variant 4 was later justified by manufacturers with the fact that many of the exploits affect web browsers and these were already fixed in deployed mitigations for previous variants. This decision also reveals that the industry may not wish to compromise performance over security, considered one of the most important product benchmarks and a key differentiator among manufacturers.

The Unknown but Expected Vulnerability

This incident revived the comments from different industry CEOs predicting that these type of flaws would most likely happen again. Unfortunately, It turns out they were true, throwing uncertainty and distrust into consumers.

The problems are rooted in the trade-off between performance and security. Computing capacity has doubled every 18 months, in line with Moore’s law. Processors were optimised for performance, without basic questions being asked about whether their design was secure. The foundational question will remain whether manufacturers will be able to do a complete processor re-design compromising performance in favour of better security designs.

In the meantime, operators of essential services and digital services providers[1], in their responsibility to manage risks associated with the security of network and information systems, should reconsider maintaining this vulnerable technology running in their environments.

Recommendations

• End-users are encouraged to keep their systems up-to-date, as it’s one of the easiest ways to ensure that always have the latest protections.
• For larger scale infrastructures, security teams and system administrators are advised to assess the exposure and level of risk these vulnerabilities introduce into their environment, weighing between operational and security requirements.
• Patch planning and prioritization will be required in certain environments. Past examples of side effects and failed patches released by soft- hardware vendors may result in much higher risk to an already vulnerable infrastructure.
• For critical infrastructure (operators of essential services and digital services providers) system owners, the risk of maintaining vulnerable equipment will require proper assessment, factored into organizations risk management plan. The fact that some microprocessor manufacturers are unable to fully eradicate these issues, urges these organizations to re-evaluate their risk exposure.
• Revision cycles of existing security architecture need to be foreseen, especially for critical infrastructure operators. According to the assessed risk level, they might need to revise their security architecture to cope with unsecure, yet indispensable components for the service provisioning.
• A follow up with microprocessor manufactures and software vendors to look for the latest mitigation strategy and further updates.
• Hardware vendors will need to concentrate on security issues in the architecture/design of their products. Depending on the impact level of possible exploitations of emerging vulnerabilities, such a strategy will certainly pay off.