{"id":54377,"date":"2025-09-22T12:24:30","date_gmt":"2025-09-22T16:24:30","guid":{"rendered":"https:\/\/www.kaspersky.com\/blog\/?p=54377"},"modified":"2025-09-22T12:24:30","modified_gmt":"2025-09-22T16:24:30","slug":"vmscape-spectre-attack","status":"publish","type":"post","link":"https:\/\/www.kaspersky.com\/blog\/vmscape-spectre-attack\/54377\/","title":{"rendered":"Virtual-machine escape \u2013 in a Spectre v2 attack"},"content":{"rendered":"

A team of researchers at the Swiss Federal Institute of Technology in Zurich (ETH Zurich) has published a research paper<\/a> demonstrating how a Spectre v2 attack can be used for a sandbox escape in a virtualized environment. With access to only a single isolated virtual machine, the researchers were able to steal valuable data normally accessible only to the server administrator. Servers based on AMD CPUs (including AMD\u2019s newest \u2013 with Zen\u00a05 architecture) or Intel\u2019s Coffee Lake are susceptible to the attack.<\/p>\n

The danger of Spectre attacks for virtual environments<\/h2>\n

We regularly write about CPU vulnerabilities that employ speculative execution, where standard hardware features are exploited to steal secrets. You can read our previous posts on this subject, which describe the general principles of these attacks in detail, here<\/a>, here<\/a>, and here<\/a>.<\/p>\n

Although this type of vulnerability was first discovered back in 2018, up until this paper researchers haven\u2019t demonstrated a single realistic attack. All their efforts have culminated in the notion that, theoretically, a sophisticated and targeted Spectre-like attack is feasible. Furthermore, in most of these papers, the researchers restricted themselves to the most basic attack scenario: they\u2019d take a computer, install malware on it, and then use the CPU hardware vulnerability to steal secrets. The drawback of this approach is that if an attacker successfully installs malware on a PC, they can steal data in numerous other, significantly simpler methods. Because of this, Spectre and similar attacks are unlikely to ever pose a threat to end-user devices. However, when it comes to cloud environments, one shouldn\u2019t dismiss Spectre.<\/p>\n

Imagine a provider that rents virtual servers to organizations or individuals. Each client is assigned their own virtual machine, which allows them to run any software they want. Other clients\u2019 virtual systems can be running on the same server. Separating data-access privileges is crucial in this situation. You must prevent an attacker who has gained access to one virtual machine from reading the confidential data of an adjacent client, or compromising the provider\u2019s infrastructure by gaining access to the host\u2019s data. It is precisely in this scenario that Spectre attacks start appearing as a significantly more perilous threat.<\/p>\n

VMScape: a practical look at a Spectre v2 attack<\/h2>\n

In previous research papers on the feasibility of the Spectre attack, researchers didn\u2019t delve into a realistic attack scenario. For an academic paper, this is normal. A theoretical proof of concept for a data leak is typically enough to get CPU makers and software developers to beef up their defenses and develop countermeasures.<\/p>\n

The authors of the new paper from ETH Zurich directly address this gap, pointing out that previously examined scenarios for attacks on virtualized environments \u2013 such as those in this paper<\/a>, also by ETH Zurich \u2013 made an extremely broad assumption: that the attackers had already managed to install malware on the host. Just like with attacks on regular desktop computers, this doesn\u2019t make much practical sense. If the server is already compromised, the damage is already done.<\/p>\n

The new attack proposed in their paper \u2013 dubbed VMScape \u2013 uses the same branch target injection<\/em> mechanism as the one found in all attacks since Spectre v2. We\u2019ve talked about it several times before<\/a>, but here\u2019s a quick summary.<\/p>\n

Branch target injection is a way to train a CPU\u2019s branch prediction system, which speeds up programs by using speculative execution<\/em>. This means the CPU tries to run the next set of commands before it even knows the results of the previous computations. If it guesses the right direction (branch) the software will take, the performance significantly increases. If it guesses wrong, the results are simply discarded.<\/p>\n

Branch target injection is an attack during which an attacker can trick the CPU into accessing secret data and move it into the cache during speculative execution. The attacker then retrieves this data indirectly through a side channel.<\/p>\n

The researchers discovered that the privilege separation between the host and guest operating systems during speculative execution is imperfect. This allows for a new version of the branch target injection attack, which they\u2019ve named \u201cVirtualization-based Spectre-BTI\u201d or vBTI.<\/p>\n

As a result, the researchers were able to read arbitrary data from the host\u2019s memory while only having access to a virtual machine with default settings. The data reading speed was 32\u00a0bytes per second on an AMD Zen\u00a04 CPU, with nearly 100% reliability. That\u2019s fast enough to steal things like data encryption keys, which opens a direct path to stealing information from adjacent virtual machines.<\/p>\n

Is VMScape a threat in the real world?<\/h2>\n

AMD CPUs with Zen architecture from the first through the latest fifth generation have proved vulnerable to this attack. This is because of the subtle differences in how these CPUs implement Spectre attack protections, as well as the unique way the authors\u2019 vBTI primitives operate. For Intel CPUs, this attack is only possible on servers with older Coffee Lake CPUs from 2017. Newer Intel architectures have improved protections that make the current version of the VMScape attack impossible.<\/p>\n

The researchers\u2019 achievement was designing the first-ever Spectre v2 attack in a virtual environment that\u2019s close to real-world conditions. It doesn\u2019t rely on overly permissive assumptions or crutches like malicious hypervisor-level software. The VMScape attack is effective; it bypasses many standard security measures, including KASLR, and successfully steals a valuable secret: an encryption key.<\/p>\n

Fortunately, immediately after designing the attack, the researchers also proposed a fix. The issue was assigned the vulnerability identifier CVE-2025-40300<\/a>, and it was patched in the Linux kernel. This particular patch doesn\u2019t significantly reduce computational performance, which is often a concern with software-based protections against Spectre attacks.<\/p>\n

Methods for protecting confidential data in virtual environments have existed for a while. AMD has a technology named \u201cSecure Encrypted Virtualization\u201d and its subtype, SEV-SNP<\/a>, while Intel has Trusted Domain Extensions (TDX). These technologies encrypt secrets, making it pointless to try to steal them directly. The researchers confirmed that SEV provides additional protection against the VMScape attack on AMD CPUs. In other words, a real-world VMScape attack against modern servers is unlikely. However, with each new study, Spectre attacks look more and more realistic.<\/p>\n

Despite the academic nature of the research, attacks that exploit speculative execution in modern CPUs remain relevant. Operators of virtualized environments should continue to consider these vulnerabilities and potential attacks in their threat models.<\/p>\n\n","protected":false},"excerpt":{"rendered":"

A fresh research paper shows how complex vulnerabilities in CPUs can be leveraged in the most pertinent attacks on cloud-based systems.<\/p>\n","protected":false},"author":665,"featured_media":54378,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1999,3051],"tags":[3116,4675,1104],"class_list":{"0":"post-54377","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-business","8":"category-enterprise","9":"tag-cpu","10":"tag-side-channel-attacks","11":"tag-virtualization"},"hreflang":[{"hreflang":"x-default","url":"https:\/\/www.kaspersky.com\/blog\/vmscape-spectre-attack\/54377\/"},{"hreflang":"en-in","url":"https:\/\/www.kaspersky.co.in\/blog\/vmscape-spectre-attack\/29570\/"},{"hreflang":"en-ae","url":"https:\/\/me-en.kaspersky.com\/blog\/vmscape-spectre-attack\/24667\/"},{"hreflang":"en-gb","url":"https:\/\/www.kaspersky.co.uk\/blog\/vmscape-spectre-attack\/29496\/"},{"hreflang":"es-mx","url":"https:\/\/latam.kaspersky.com\/blog\/vmscape-spectre-attack\/28594\/"},{"hreflang":"es","url":"https:\/\/www.kaspersky.es\/blog\/vmscape-spectre-attack\/31467\/"},{"hreflang":"ru","url":"https:\/\/www.kaspersky.ru\/blog\/vmscape-spectre-attack\/40550\/"},{"hreflang":"tr","url":"https:\/\/www.kaspersky.com.tr\/blog\/vmscape-spectre-attack\/13821\/"},{"hreflang":"fr","url":"https:\/\/www.kaspersky.fr\/blog\/vmscape-spectre-attack\/23236\/"},{"hreflang":"pt-br","url":"https:\/\/www.kaspersky.com.br\/blog\/vmscape-spectre-attack\/24307\/"},{"hreflang":"ru-kz","url":"https:\/\/blog.kaspersky.kz\/vmscape-spectre-attack\/29671\/"},{"hreflang":"en-au","url":"https:\/\/www.kaspersky.com.au\/blog\/vmscape-spectre-attack\/35423\/"},{"hreflang":"en-za","url":"https:\/\/www.kaspersky.co.za\/blog\/vmscape-spectre-attack\/35051\/"}],"acf":[],"banners":"","maintag":{"url":"https:\/\/www.kaspersky.com\/blog\/tag\/side-channel-attacks\/","name":"side-channel attacks"},"_links":{"self":[{"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts\/54377","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/users\/665"}],"replies":[{"embeddable":true,"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/comments?post=54377"}],"version-history":[{"count":4,"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts\/54377\/revisions"}],"predecessor-version":[{"id":54382,"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts\/54377\/revisions\/54382"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/media\/54378"}],"wp:attachment":[{"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/media?parent=54377"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/categories?post=54377"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/tags?post=54377"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}