BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News TLBleed Can Leak Cryptographic Keys from CPUs Snooping on TLBs

TLBleed Can Leak Cryptographic Keys from CPUs Snooping on TLBs

This item in japanese

Bookmarks

A new side-channel vulnerability affecting Intel processors, known as TLBleed, can leak information by snooping on Translation Look-aside Buffers (TLBs), writes VUsec security researcher Ben Gras.

Gras, who will present his accomplishment at next Blackhat 2018 conference, claims he could extract encryption keys used by GPG:

Our TLBleed exploit successfully leaks a 256-bit EdDSA key from libgcrypt (used in e.g. GPG) with a 98% success rate after just a single observation of signing operation on a co-resident hyperthread and just 17 seconds of analysis time.

TLBs are a kind of cache that is used to speed up translation of frequently used virtual addresses into physical memory. TLBleed shows a way for a hyperthread to access information belonging to another hyperthread running on the same core by using TLBs to detect when valuable information is available in the CPU registers. This vulnerability is not related to Spectre and Meltdown, both of which exploits speculative execution glitches to leak information from the CPU cache.

What is most concerning about this vulnerability is the fact it uses data accesses and not the code path being executed, which means existing protections for already known side-channel attacks may be not effective against TLBleed. Indeed, Gras mentions a second attack based on TLBleed that can leak bits from the recent libgcrypt version that included a side-channel resistant RSA implementation. This second type of attack leverages machine learning techniques to be more effective. Writing for The Register, Chris Williams, who had access to a white paper by Gras and others, explained that the team used a classifier to identify the execution of sensitive operations, including cryptographic operations, based on TLB latencies.

Intel will not address this vulnerability, arguing that a program that correctly guards itself against other kinds of side-channel attacks, e.g., by making its patterns of data access look the same both when using cryptographic keys and when not, will also be immune to TLBleed. While acknowledging this, Gras maintains that there are very few programs that are so perfectly written as to prevent side-channel attacks, as the leakage of RSA keys from libgcrypt shows.

This is not the stance taken by OpenBSD maintainers, who decided to disable the use of simultaneous multi-threading (SMT) for Intel processors:

Since many modern machines no longer provide the ability to disable Hyper-threading in the BIOS setup, provide a way to disable the use of additional processor threads in our scheduler. And since we suspect there are serious risks, we disable them by default.

OpenBSD will extend this policy to other CPUs and other architectures in the future.

A less intrusive OS-level mitigations to TLBleed would be preventing the concurrent execution of two threads belonging to different processes on the same core, which is not always a trivial change to the OS scheduler, though.

It is not yet clear whether other vendors will do anything to address TLBleed at the OS level or if Cloud providers will offer the possibility to prevent two different virtual machines from sharing the same core. InfoQ will continue reporting as new information will become available.

Rate this Article

Adoption
Style

BT