A recently discovered flaw in how CPUs handle multithreading could leak cryptography keys, though Intel is declining to patch the issue.
Yet another critical flaw has been found to affect Intel CPUs, according to researchers at VUsec, the Systems and Network Security Group at Vrije Universiteit Amsterdam, as reported by The Register. The vulnerability, called TLBleed, leverages flaws in protection in the CPU's translation lookaside buffer (TLB). According to the researchers, the vulnerability can be used to extract cryptography keys from another running program with a minimum of 98% success rate depending on the processor used.
TLBleed is exploited through the implementation of symmetric multithreading (SMT), otherwise marketed as Hyper-Threading by Intel. With this enabled, a single core can execute multiple (generally two) threads simultaneously, sharing resources inside that core, including TLB.
Broadly speaking, because of these shared resources, if two programs are running in the same core, it is possible for one thread to exfiltrate data from the other thread by examining the timings of when resources are accessed, and comparing that to known information about how a given app would operate, based on available source code (in the proof of concept), and the use of artificial intelligence (AI) to determine when a program is executing a sensitive operation by inspecting changes to TLB.
As it is, this attack requires malware or a malicious user to have access to the system. While easier avenues for attacks exist—and there is no known instance of this being exploited in the wild—it is concerning for public cloud users, as other guest instances on the same hardware could attempt to use this to exfiltrate data from threads running in other cores.
SEE: Cybersecurity strategy research: Common tactics, issues with implementation, and effectiveness (Tech Pro Research)
While the whitepaper describing the finer technical details of TLBleed is set to be released next week—Ben Gras, one of the researchers involved, is giving a presentation at the Black Hat USA conference in August—a draft version has been shared in OS development circles, as well as with The Register.
Early last week, the developers of OpenBSD disabled SMT entirely, as a mitigation to the vulnerability. In a public mailing list post on June 19th, OpenBSD maintainer Mark Kettenis wrote that: "We really should not run different security domains on different processor threads of the same core. Unfortunately changing our scheduler to take this into account is far from trivial."
Additionally, Theo de Raadt noted that the rationale behind this move is that the developers "wanted to get a usable mitigation for the problem into public. Maybe Intel has solutions with less overhead. But Intel excluded us from conversation so we don't know what those solutions might be. So we follow a pattern of immediately releasing a rough solution, which we can retract if a cheaper solution becomes published."
Intel's position on this is somewhat peculiar, as the company has indicated that existing mitigations are sufficient to prevent this issue, and has declined to request a CVE to identify the flaw, as is standard. The Register report also indicates that Intel has declined to pay a bug bounty for this discovery via HackerOne, which is within the scope of the requirements Intel lists as being a side-channel attack, which Gras indicated to The Register as "goalpost-moving."
Exploitation of, and patches for, TLBleed are likely to be more technically involved than the OpenBSD strategy of disabling SMT entirely, as ensuring that schedulers do not place processes of different security levels in the same core is a significant undertaking. Even relative to Intel CPUs, the exact implementation of SMT is not consistent across product generations, making a mitigation that works on one processor family potentially ineffectual on a different family. While Gras indicated that AMD Zen processors are also likely affected, AMD's Bulldozer architecture is only a partial SMT implementation, and may not be so affected by this discovery.
Update: Intel has provided the following statement about TLBleed to TechRepublic:
Intel has received notice of research from Vrije Universiteit Amsterdam, which outlines a potential side-channel analysis vulnerability referred to as TLBleed. This issue is not reliant on speculative execution, and is therefore unrelated to Spectre or Meltdown. Research on side-channel analysis methods often focuses on manipulating and measuring the characteristics (e.g. timing) of shared hardware resources. These measurements can potentially allow researchers to extract information about the software and related data. TLBleed uses the Translation Lookaside Buffer (TLB), a cache common to many high performance microprocessors that stores recent address translations from virtual memory to physical memory. Software or software libraries such as Intel® Integrated Performance Primitives Cryptography version U3.1 - written to ensure constant execution time and data independent cache traces should be immune to TLBleed. Protecting our customers' data and ensuring the security of our products is a top priority for Intel and we will continue to work with customers, partners and researchers to understand and mitigate any vulnerabilities that are identified.
Big takeaways for tech leaders:
- TLBleed leverages flaws in protection in the CPU's translation lookaside buffer, which can be exploited to extract cryptography keys from another running program with a minimum 98% success rate.
- The vulnerability is concerning for public cloud users, as other guest instances on the same hardware could attempt to use this to exfiltrate data from threads running in other cores.
- 10 ways to raise your users' cybersecurity IQ (free PDF) (TechRepublic)
- Cisco patches critical Nexus flaws: Are your switches vulnerable? (ZDNet)
- Spectre and Meltdown: Cheat sheet (TechRepublic)
- Another day, another Intel CPU security hole: Lazy State (ZDNet)
- Microsoft Edge users should patch to avoid data-scraping Wavethrough vulnerability (TechRepublic)