New Spectre-v2 BTR Attack Leaks Linux Root Password Hashes

Academics disclosed a Spectre-v2 variant called BTR that bypasses existing mitigations and recovers Linux root password hashes on Intel systems in minutes.
Table of Contents
    Add a header to begin generating the table of contents

    Academic researchers disclosed a new Spectre CPU vulnerability variant called Branch Target Reuse, or BTR, that bypasses existing Spectre-v2 mitigations and can recover Linux root password hashes on Intel-based systems in an average of three to five minutes, according to the disclosure published September 29.

    VUSec and Scuola Superiore Sant’Anna Researchers Behind BTR

    The vulnerability was disclosed by academics from VUSec and Scuola Superiore Sant’Anna. BTR affects JIT engines used inside web browsers, language runtimes, and operating system kernels, and the researchers say it spans multiple CPU vendors rather than being confined to a single chipmaker’s hardware. That cross-vendor reach distinguishes BTR from many prior speculative-execution disclosures that affected only one manufacturer’s processors.

    Attack Reuses Branch Target Predictions to Bypass Spectre-v2 Defenses

    Spectre-v2 mitigations deployed by CPU vendors and operating system developers were designed to prevent attackers from manipulating branch prediction to leak data across security boundaries. BTR works around those defenses specifically by reusing branch target predictions in a way the existing mitigations do not account for, according to the researchers. The technique effectively finds a gap in protections that were already assumed to close off this class of speculative-execution attack.

    Intel, AMD, and Arm Processors All Affected

    The researchers state that BTR affects Intel, AMD, and Arm processors, making it a hardware design issue that spans the three dominant CPU architecture families rather than a defect isolated to one vendor’s implementation. Because JIT engines are present in nearly all modern web browsers and many programming language runtimes, the population of systems running software capable of triggering the vulnerable code path is large.

    Root Password Hash Recovery Demonstrated in Three to Five Minutes

    On Intel-based Linux systems specifically, the research team demonstrated recovering root password hashes in an average of three to five minutes using the BTR technique. Recovering a password hash does not immediately grant an attacker the plaintext password, but it hands them material that can be fed into offline password-cracking tools, and root hashes are a particularly high-value target given the privileges tied to that account on a Linux system.

    Cloud Providers and Multi-Tenant Systems Face the Highest Exposure

    Speculative-execution attacks of this kind are especially significant for cloud providers and any environment where multiple tenants or users share the same physical hardware, since the attack model for Spectre-class vulnerabilities typically involves one process reading data it should not have access to across a boundary the CPU is supposed to enforce. A minutes-long path to root credential material on affected Linux systems raises the stakes for any shared-infrastructure operator running unpatched hardware and software.

    The researchers disclosed their findings to CPU vendors ahead of the public technical paper, giving chipmakers advance notice before the publication. Mitigations for BTR are expected to arrive through microcode updates from the affected processor vendors combined with kernel-level updates from operating system distributions, mirroring the two-layer patching approach used for earlier Spectre variants. Organizations running shared or multi-tenant Linux infrastructure are being told to watch for vendor advisories addressing BTR specifically, since the general Spectre-v2 mitigations already deployed on their systems do not close this particular gap.

    Because BTR targets JIT engines rather than a single application, the vulnerable code path can be reached through ordinary use of a modern web browser, a language runtime executing untrusted code, or the operating system kernel itself, depending on how each is implemented. That breadth means the practical fix will likely require coordinated updates across browser vendors, runtime maintainers, and Linux distribution kernels, in addition to the microcode-level changes chipmakers ship, rather than a single patch closing the gap everywhere at once.

    Related Posts