{"id":24307,"date":"2025-10-08T16:19:30","date_gmt":"2025-10-08T19:19:30","guid":{"rendered":"https:\/\/www.kaspersky.com.br\/blog\/?p=24307"},"modified":"2025-10-08T16:19:30","modified_gmt":"2025-10-08T19:19:30","slug":"vmscape-spectre-attack","status":"publish","type":"post","link":"https:\/\/www.kaspersky.com.br\/blog\/vmscape-spectre-attack\/24307\/","title":{"rendered":"Escape de m\u00e1quina virtual em um ataque Spectre v2"},"content":{"rendered":"<p>Uma equipe de pesquisadores do Instituto Federal de Tecnologia Su\u00ed\u00e7o (ETH Zurich), em Zurique, <a href=\"https:\/\/comsec-files.ethz.ch\/papers\/vmscape_sp26.pdf\" target=\"_blank\" rel=\"noopener nofollow\">publicou um estudo<\/a> demonstrando como um ataque Spectre v2 pode ser utilizado no escape de um sandbox em ambiente virtualizado. Os pesquisadores tiveram acesso a apenas uma m\u00e1quina virtual isolada e conseguiram roubar dados valiosos, que normalmente apenas o administrador do servidor conseguiria acessar. Servidores em CPUs AMD (incluindo o mais recente, com arquitetura Zen 5) ou Coffee Lake da Intel s\u00e3o suscet\u00edveis ao ataque.<\/p>\n<h2>A amea\u00e7a dos ataques Spectre em ambientes virtuais<\/h2>\n<p>Regularmente escrevemos sobre vulnerabilidades de CPU que empregam execu\u00e7\u00e3o especulativa, em que recursos de hardware padr\u00e3o s\u00e3o explorados para roubar segredos. Confira nossas publica\u00e7\u00f5es anteriores sobre esse assunto <a href=\"https:\/\/www.kaspersky.com\/blog\/retbleed-practical-exploitation\/54169\/\" target=\"_blank\" rel=\"noopener nofollow\">aqui<\/a> , <a href=\"https:\/\/www.kaspersky.com\/blog\/retbleed-vulnerability\/45155\/\" target=\"_blank\" rel=\"noopener nofollow\">aqui<\/a> e <a href=\"https:\/\/www.kaspersky.com\/blog\/spectre-meltdown-in-practice\/43525\/\" target=\"_blank\" rel=\"noopener nofollow\">aqui<\/a>. Nelas, descrevemos em detalhes os princ\u00edpios gerais desses ataques.<\/p>\n<p>Apesar de esse tipo de vulnerabilidade ter sido descoberto em 2018, nenhum ataque realista havia sido demonstrado pelos pesquisadores at\u00e9 a publica\u00e7\u00e3o deste artigo. Todos os esfor\u00e7os dos pesquisadores resultaram na ideia de que, teoricamente, um ataque sofisticado e direcionado, semelhante ao Spectre, \u00e9 vi\u00e1vel. Al\u00e9m disso, na maioria desses artigos, os pesquisadores se restringiram ao cen\u00e1rio de ataque mais b\u00e1sico: instalar malware em um computador e aproveitar a vulnerabilidade da CPU para roubar segredos. A desvantagem dessa abordagem \u00e9 que, se um atacante conseguir instalar o malware em um PC, ele poder\u00e1 roubar os dados utilizando v\u00e1rios outros m\u00e9todos bem mais simples. Por isso, \u00e9 improv\u00e1vel que ataques como o Spectre e similares representem uma amea\u00e7a a dispositivos de usu\u00e1rio final. No entanto, em ambientes de nuvem, o Spectre n\u00e3o deve ser subestimado.<\/p>\n<p>Suponha que um provedor alugue servidores virtuais para organiza\u00e7\u00f5es ou indiv\u00edduos. Cada cliente recebe sua pr\u00f3pria m\u00e1quina virtual, onde pode executar qualquer software que deseja. Os sistemas virtuais de outros clientes podem ser executados no mesmo servidor. Assim, \u00e9 essencial separar as permiss\u00f5es de acesso aos dados. \u00c9 necess\u00e1rio impedir que um atacante que obteve acesso a uma m\u00e1quina virtual possa ler os dados confidenciais de um cliente adjacente, ou que comprometa a infraestrutura do provedor obtendo acesso aos dados do host. \u00c9 exatamente nesse cen\u00e1rio que os ataques Spectre come\u00e7am a se tornar uma amea\u00e7a significativamente mais perigosa.<\/p>\n<h2>VMScape: uma vis\u00e3o pr\u00e1tica de um ataque Spectre v2<\/h2>\n<p>Nos estudos anteriores sobre a viabilidade do ataque Spectre, os pesquisadores n\u00e3o se aprofundaram em um cen\u00e1rio realista. Para um artigo acad\u00eamico, isso \u00e9 normal. Uma comprova\u00e7\u00e3o do conceito sobre um vazamento de dados costuma ser suficiente para fazer com que os fabricantes de CPU e desenvolvedores de software reforcem suas defesas e desenvolvam contramedidas.<\/p>\n<p>Os autores do novo artigo do ETH Zurich abordam diretamente essa brecha, deixando claro que os cen\u00e1rios de ataques em ambientes virtualizados examinados anteriormente (como os <a href=\"https:\/\/comsec.ethz.ch\/wp-content\/files\/bprc_sec25.pdf\" target=\"_blank\" rel=\"noopener nofollow\">deste artigo<\/a>, tamb\u00e9m do ETH Zurich) partiam de uma suposi\u00e7\u00e3o bastante ampla: que os invasores j\u00e1 haviam conseguido instalar malware no host. Assim como nos ataques a computadores desktop comuns, isso n\u00e3o tem muito sentido pr\u00e1tico. Se o servidor j\u00e1 estiver comprometido, o dano j\u00e1 aconteceu.<\/p>\n<p>O novo ataque, chamado de VMScape, proposto em seu artigo, utiliza o mesmo mecanismo de <em>inje\u00e7\u00e3o de alvo de ramifica\u00e7\u00e3o<\/em> presente em todos os ataques desde o Spectre v2. J\u00e1 falamos sobre isso v\u00e1rias vezes <a href=\"https:\/\/www.kaspersky.com\/blog\/spectre-meltdown-in-practice\/43525\/\" target=\"_blank\" rel=\"noopener nofollow\">aqui<\/a>, mas faremos um breve resumo.<\/p>\n<p>A inje\u00e7\u00e3o de alvo de ramifica\u00e7\u00e3o \u00e9 uma forma de treinar o sistema de previs\u00e3o de ramifica\u00e7\u00e3o de uma CPU, acelerando os programas com a <em>execu\u00e7\u00e3o especulativa<\/em>. Isso significa que a CPU tenta executar o pr\u00f3ximo conjunto de comandos antes de obter os resultados dos c\u00e1lculos anteriores. Caso ele acerte o caminho, ou ramifica\u00e7\u00e3o, que o software seguir\u00e1, o desempenho aumenta significativamente. Se ele errar, os resultados s\u00e3o descartados.<\/p>\n<p>A inje\u00e7\u00e3o de alvo de ramifica\u00e7\u00e3o \u00e9 um ataque em que um atacante engana a CPU para acessar dados secretos e os move para o cache durante a execu\u00e7\u00e3o especulativa. Em seguida, o atacante recupera esses dados indiretamente, utilizando um canal lateral.<\/p>\n<p>Os pesquisadores descobriram que a segrega\u00e7\u00e3o das permiss\u00f5es entre os sistemas operacionais do host e convidado durante a execu\u00e7\u00e3o especulativa \u00e9 insuficiente. Isso permite uma nova vers\u00e3o do ataque de inje\u00e7\u00e3o de alvo de ramifica\u00e7\u00e3o, que chamaram de \u201cSpectre-BTI baseado em virtualiza\u00e7\u00e3o\u201d ou vBTI.<\/p>\n<p>Como resultado, os pesquisadores conseguiram ler dados arbitr\u00e1rios da mem\u00f3ria do host, mesmo com um acesso a uma m\u00e1quina virtual com configura\u00e7\u00e3o padr\u00e3o. A velocidade de leitura de dados foi de 32 bytes por segundo em uma CPU AMD Zen 4, com quase 100% de confiabilidade. Isso \u00e9 r\u00e1pido o suficiente para roubar chaves de criptografia de dados, o que abre um caminho direto para roubar informa\u00e7\u00f5es de m\u00e1quinas virtuais adjacentes.<\/p>\n<h2>O VMScape \u00e9 uma amea\u00e7a no mundo real?<\/h2>\n<p>Da primeira at\u00e9 a quinta gera\u00e7\u00e3o, as CPUs AMD com arquitetura Zen provaram ser vulner\u00e1veis a esse ataque. Isso ocorre por conta das diferen\u00e7as sutis em como essas CPUs implementam as prote\u00e7\u00f5es contra ataques Spectre, bem como pela forma como os vBTI primitivos dos autores operam. Em CPUs Intel, esse ataque s\u00f3 \u00e9 poss\u00edvel em servidores com processadores Coffee Lake mais antigos, de 2017. As arquiteturas Intel mais recentes t\u00eam prote\u00e7\u00f5es otimizadas que impossibilitam a vers\u00e3o atual do ataque VMScape.<\/p>\n<p>O \u00eaxito dos pesquisadores foi desenvolver o primeiro ataque Spectre v2 em um ambiente virtual pr\u00f3ximo \u00e0s condi\u00e7\u00f5es reais. Esse cen\u00e1rio n\u00e3o depende de suposi\u00e7\u00f5es excessivamente permissivas nem em artif\u00edcios como software malicioso no hipervisor. O ataque VMScape \u00e9 eficaz, pois consegue ignorar muitas medidas padr\u00f5es de seguran\u00e7a, incluindo KASLR, e consegue roubar um segredo valioso como a chave de criptografia.<\/p>\n<p>Felizmente, logo ap\u00f3s desenvolverem o ataque, os pesquisadores tamb\u00e9m propuseram uma corre\u00e7\u00e3o. O problema recebeu o identificador de vulnerabilidade <a href=\"https:\/\/www.cve.org\/CVERecord?id=CVE-2025-40300\" target=\"_blank\" rel=\"noopener nofollow\">CVE-2025-40300<\/a> e foi corrigido no kernel do Linux. Esse patch espec\u00edfico n\u00e3o reduz o desempenho computacional de maneira significativa, o que costuma ser uma preocupa\u00e7\u00e3o com prote\u00e7\u00f5es baseadas em software contra ataques Spectre.<\/p>\n<p>M\u00e9todos de prote\u00e7\u00e3o de dados confidenciais em ambientes virtuais s\u00e3o conhecidos h\u00e1 algum tempo. A AMD possui uma tecnologia chamada \u201cSecure Encrypted Virtualization (SEV)\u201d e seu subtipo <a href=\"https:\/\/www.kaspersky.com\/blog\/badram-cpu-attack\/52849\/\" target=\"_blank\" rel=\"noopener nofollow\">SEV-SNP<\/a>, enquanto a Intel conta com Trusted Domain Extensions (TDX). Essas tecnologias criptografam os segredos, tornando in\u00fatil tentar roub\u00e1-los diretamente. Os pesquisadores confirmaram que o SEV fornece prote\u00e7\u00e3o adicional contra o ataque VMScape em CPUs AMD. Em outras palavras, um ataque VMScape real contra servidores modernos \u00e9 improv\u00e1vel. No entanto, a cada novo estudo, os ataques Spectre parecem cada vez mais vi\u00e1veis.<\/p>\n<p>Apesar da natureza acad\u00eamica da pesquisa, os ataques que exploram a execu\u00e7\u00e3o especulativa em CPUs modernas continuam sendo significativos. Os operadores de ambientes virtualizados devem continuar considerando essas vulnerabilidades e poss\u00edveis ataques em seus modelos de amea\u00e7a.<\/p>\n<input type=\"hidden\" class=\"category_for_banner\" value=\"kaspersky-next\"><input type=\"hidden\" class=\"placeholder_for_banner\" data-cat_id=\"kaspersky-next\" value=\"22429\">\n","protected":false},"excerpt":{"rendered":"<p>Um novo artigo de pesquisa mostra como vulnerabilidades complexas em CPUs podem ser exploradas nos ataques mais significativos a sistemas em nuvem.<\/p>\n","protected":false},"author":665,"featured_media":24318,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1119,1655,1656],"tags":[3383,1790,722],"class_list":{"0":"post-24307","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-business","8":"category-enterprise","9":"category-smb","10":"tag-ataques-por-canal-lateral","11":"tag-cpu","12":"tag-virtualizacao"},"hreflang":[{"hreflang":"pt-br","url":"https:\/\/www.kaspersky.com.br\/blog\/vmscape-spectre-attack\/24307\/"},{"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":"ar","url":"https:\/\/me.kaspersky.com\/blog\/vmscape-spectre-attack\/12839\/"},{"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":"it","url":"https:\/\/www.kaspersky.it\/blog\/vmscape-spectre-attack\/30137\/"},{"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":"x-default","url":"https:\/\/www.kaspersky.com\/blog\/vmscape-spectre-attack\/54377\/"},{"hreflang":"fr","url":"https:\/\/www.kaspersky.fr\/blog\/vmscape-spectre-attack\/23236\/"},{"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.br\/blog\/tag\/ataques-por-canal-lateral\/","name":"ataques por canal lateral"},"_links":{"self":[{"href":"https:\/\/www.kaspersky.com.br\/blog\/wp-json\/wp\/v2\/posts\/24307","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.kaspersky.com.br\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.kaspersky.com.br\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.kaspersky.com.br\/blog\/wp-json\/wp\/v2\/users\/665"}],"replies":[{"embeddable":true,"href":"https:\/\/www.kaspersky.com.br\/blog\/wp-json\/wp\/v2\/comments?post=24307"}],"version-history":[{"count":3,"href":"https:\/\/www.kaspersky.com.br\/blog\/wp-json\/wp\/v2\/posts\/24307\/revisions"}],"predecessor-version":[{"id":24316,"href":"https:\/\/www.kaspersky.com.br\/blog\/wp-json\/wp\/v2\/posts\/24307\/revisions\/24316"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.kaspersky.com.br\/blog\/wp-json\/wp\/v2\/media\/24318"}],"wp:attachment":[{"href":"https:\/\/www.kaspersky.com.br\/blog\/wp-json\/wp\/v2\/media?parent=24307"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.kaspersky.com.br\/blog\/wp-json\/wp\/v2\/categories?post=24307"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.kaspersky.com.br\/blog\/wp-json\/wp\/v2\/tags?post=24307"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}