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.
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.
Commentaires récents