{"id":25334,"date":"2026-09-23T07:58:01","date_gmt":"2026-09-23T10:58:01","guid":{"rendered":"https:\/\/www.kaspersky.com.br\/blog\/?p=25334"},"modified":"2026-09-22T08:01:21","modified_gmt":"2026-09-22T11:01:21","slug":"gputhor-rowhammer-class-attack","status":"publish","type":"post","link":"https:\/\/www.kaspersky.com.br\/blog\/gputhor-rowhammer-class-attack\/25334\/","title":{"rendered":"GPUThor: mais uma tentativa de ataque a servidores por meio da GPU"},"content":{"rendered":"<p>Como um servidor industrial pode ser comprometido por meio da sua GPU sem deixar rastros? Um ataque t\u00e3o complexo e, a princ\u00edpio, te\u00f3rico, normalmente aproveitaria as vulnerabilidades do hardware. Isso nem sequer diz respeito a falhas de projeto no pr\u00f3prio hardware, mas \u00e0s particularidades de seu funcionamento, \u00e0s vezes at\u00e9 em n\u00edvel f\u00edsico. Um <a href=\"https:\/\/gururaj-s.github.io\/assets\/pdf\/CCS26_GPUThor.pdf\" target=\"_blank\" rel=\"noopener nofollow\">artigo<\/a> recente de pesquisadores canadenses da Universidade de Toronto descreve o GPUThor: um ataque Rowhammer novo e mais efetivo que explora precisamente esse tipo de comportamento de hardware na mem\u00f3ria de v\u00eddeo.<\/p>\n<h2>Rowhammer e placas de v\u00eddeo<\/h2>\n<p>O GPUThor baseia-se na ideia por tr\u00e1s do ataque original \u00e0 RAM, proposto pela primeira vez em 2014 na <a href=\"https:\/\/users.ece.cmu.edu\/~yoonguk\/papers\/kim-isca14.pdf\" target=\"_blank\" rel=\"noopener nofollow\">pesquisa<\/a> Rowhammer. O Rowhammer e todos os ataques da sua classe baseiam-se em um fato simples: as c\u00e9lulas de mem\u00f3ria n\u00e3o s\u00e3o totalmente isoladas umas das outras. O acesso repetido (ou hammering) \u00e0 mesma linha de c\u00e9lulas pode, sob determinadas condi\u00e7\u00f5es, corromper os dados (ou seja, inverter bits) nas linhas adjacentes. Depois que esse efeito for confirmado como poss\u00edvel, tudo o que resta \u00e9 encontrar uma maneira de transform\u00e1-lo em uma arma: por exemplo, acionando uma nega\u00e7\u00e3o de servi\u00e7o ou at\u00e9 mesmo executando um c\u00f3digo arbitr\u00e1rio.<\/p>\n<p>Ent\u00e3o, o que os servidores e aceleradores gr\u00e1ficos t\u00eam a ver com tudo isso? \u00c0 medida que as tecnologias de intelig\u00eancia artificial decolaram, tamb\u00e9m aumentou a demanda por hardware capaz de executar um grande n\u00famero de c\u00e1lculos paralelos semelhantes. E os aceleradores integrados nas placas de v\u00eddeo de jogos s\u00e3o uma op\u00e7\u00e3o natural para esse tipo de carga de trabalho. Isso torna os provedores de nuvem que alugam aceleradores gr\u00e1ficos para todos um alvo atraente para os ataques Rowhammer. O cen\u00e1rio hipot\u00e9tico funciona assim: um invasor compra o acesso a um chip gr\u00e1fico e o usa para tentar comprometer toda a infraestrutura do provedor. \u00c9 exatamente por isso que os ataques \u00e0 mem\u00f3ria de v\u00eddeo continuam sendo um assunto de interesse especial para os pesquisadores.<\/p>\n<h2>Como o ataque GPUThor funciona<\/h2>\n<p>Na primavera deste ano, <a href=\"https:\/\/www.kaspersky.com\/blog\/gddrhammer-geforge-gpubreach-attacks\/55607\/\" target=\"_blank\" rel=\"noopener nofollow\">tr\u00eas novos artigos<\/a> foram publicados, cada um demonstrando um ataque diferente aos aceleradores da Nvidia equipados com mem\u00f3ria GDDR6. Todos os artigos forneceram resultados bastante modestos: o maior dano foi causado quando o alvo era uma placa de v\u00eddeo para consumidores, enquanto os ataques a um acelerador de uso industrial como o Nvidia A6000 provaram ser muito menos efetivos. Al\u00e9m disso, nenhum dos ataques funcionou com a prote\u00e7\u00e3o de mem\u00f3ria ECC (c\u00f3digo de corre\u00e7\u00e3o de erros) ativada.<\/p>\n<p>O GPUThor tamb\u00e9m investiga a possibilidade de atacar aceleradores Ampere mais antigos da Nvidia com mem\u00f3ria GDDR6: os pesquisadores estudaram os modelos A4000, A4500, A5000 e A6000. Mas a efetividade do novo m\u00e9todo, medida pelo n\u00famero de c\u00e9lulas cujos dados foram alterados \u00e0 for\u00e7a, \u00e9 muito maior. Os pesquisadores tamb\u00e9m argumentam que, em teoria, a t\u00e9cnica tamb\u00e9m poderia ser aplicada a aceleradores mais novos.<\/p>\n<div id=\"attachment_25335\" style=\"width: 2026px\" class=\"wp-caption aligncenter\"><a href=\"https:\/\/media.kasperskydaily.com\/wp-content\/uploads\/sites\/94\/2026\/09\/22075627\/gputhor-rawhammer-class-attack-results.png\"><img decoding=\"async\" aria-describedby=\"caption-attachment-25335\" class=\"wp-image-25335 size-full\" title=\"gputhor-rawhammer-class-attack-results\" src=\"https:\/\/media.kasperskydaily.com\/wp-content\/uploads\/sites\/94\/2026\/09\/22075627\/gputhor-rawhammer-class-attack-results.png\" alt=\"Efetividade do ataque GPUThor\" width=\"2016\" height=\"590\"><\/a><p id=\"caption-attachment-25335\" class=\"wp-caption-text\">Efetividade do GPUThor em compara\u00e7\u00e3o com ataques anteriores. <a href=\"https:\/\/gputhor.com\/\" target=\"_blank\" rel=\"noopener nofollow\"> Fonte <\/a><\/p><\/div>\n<p>Como esses resultados foram alcan\u00e7ados? O mecanismo de defesa padr\u00e3o contra ataques Rowhammer \u00e9 chamado Target Row Refresh (TRR), que foi examinado mais de perto pelos pesquisadores canadenses. Acontece que, se o TRR detectar tentativas repetidas de acesso, ele for\u00e7ar\u00e1 uma atualiza\u00e7\u00e3o das c\u00e9lulas vizinhas, dificultando ou impossibilitando a corrup\u00e7\u00e3o de dados. Os invasores geralmente tentam derrotar o TRR acessando c\u00e9lulas aleat\u00f3rias, o que confunde o sistema de defesa e reduz a sua efetividade. Os pesquisadores descobriram que nas placas Nvidia Ampere, o TRR \u00e9 acionado apenas uma vez a cada 72 ciclos de atualiza\u00e7\u00e3o das c\u00e9lulas de mem\u00f3ria. Ap\u00f3s essa descoberta, eles aplicaram um padr\u00e3o de acesso irregular, submetendo as c\u00e9lulas-alvo a um hammering muito mais intenso do que antes. O resultado: em compara\u00e7\u00e3o ao ataque GDDR original conhecido como GPUHammer, o GPUThor acaba sendo cerca de 7 a 23 mil vezes mais efetivo.<\/p>\n<h2>Resultados e perspectivas<\/h2>\n<p>A combina\u00e7\u00e3o desse padr\u00e3o de ataque mais agressivo com outros refinamentos produziu invers\u00f5es de 72 a 377 mil bits por gigabyte. As variantes anteriores do Rowhammer produziram apenas algumas centenas, na melhor das hip\u00f3teses. Isso permitiu que os pesquisadores alcan\u00e7assem erros de bits duplos e at\u00e9 triplos. \u00c9 f\u00e1cil para o ECC corrigir um erro de bit \u00fanico, mas n\u00e3o um de bit duplo.<\/p>\n<p>O novo m\u00e9todo tamb\u00e9m demonstra os danos reais que um ataque Rowhammer pode causar: o acesso repetido \u00e0 mem\u00f3ria de v\u00eddeo usando o GPUThor aciona uma nega\u00e7\u00e3o de servi\u00e7o. Primeiro, o acelerador \u00e9 reiniciado, perdendo dados no processo e, em seguida, ele sinaliza ao administrador que precisa ser substitu\u00eddo.<\/p>\n<p>Apesar desses resultados impressionantes, os ataques GPUThor n\u00e3o s\u00e3o bem-sucedidos. Por um lado, os pesquisadores n\u00e3o foram capazes de demonstrar a execu\u00e7\u00e3o arbitr\u00e1ria de c\u00f3digo como um resultado da corrup\u00e7\u00e3o de dados, embora eles afirmem que isso \u00e9 poss\u00edvel mesmo com o ECC ativado. Por outro lado, um ataque milhares de vezes mais efetivo sugere a possibilidade te\u00f3rica de tamb\u00e9m comprometer os aceleradores mais novos, mas isso ainda n\u00e3o foi comprovado.<\/p>\n<p>Mesmo assim, os pesquisadores canadenses mostraram que os ataques Rowhammer aos aceleradores gr\u00e1ficos ainda t\u00eam um potencial inexplorado. N\u00e3o seria surpreendente se pesquisas futuras demonstrassem ataques semelhantes contra dispositivos muito mais avan\u00e7ados que antes eram considerados bastante resistentes a eles.<\/p>\n<input type=\"hidden\" class=\"category_for_banner\" value=\"mdr\"><input type=\"hidden\" class=\"placeholder_for_banner\" data-cat_id=\"mdr\" value=\"17211\">\n","protected":false},"excerpt":{"rendered":"<p>Pesquisadores demonstraram um ataque Rowhammer parcialmente efetivo contra aceleradores gr\u00e1ficos<\/p>\n","protected":false},"author":665,"featured_media":25336,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[15],"tags":[3445,1376],"class_list":["post-25334","post","type-post","status-publish","format-standard","has-post-thumbnail","category-products","tag-empresarial","tag-hardware"],"hreflang":[{"hreflang":"pt-br","url":"https:\/\/www.kaspersky.com.br\/blog\/gputhor-rowhammer-class-attack\/25334\/"},{"hreflang":"es-mx","url":"https:\/\/latam.kaspersky.com\/blog\/gputhor-rowhammer-class-attack\/29499\/"},{"hreflang":"es","url":"https:\/\/www.kaspersky.es\/blog\/gputhor-rowhammer-class-attack\/32472\/"},{"hreflang":"it","url":"https:\/\/www.kaspersky.it\/blog\/gputhor-rowhammer-class-attack\/31011\/"},{"hreflang":"ru","url":"https:\/\/www.kaspersky.ru\/blog\/gputhor-rowhammer-class-attack\/42623\/"},{"hreflang":"tr","url":"https:\/\/www.kaspersky.com.tr\/blog\/gputhor-rowhammer-class-attack\/14894\/"},{"hreflang":"x-default","url":"https:\/\/www.kaspersky.com\/blog\/gputhor-rowhammer-class-attack\/56362\/"},{"hreflang":"fr","url":"https:\/\/www.kaspersky.fr\/blog\/gputhor-rowhammer-class-attack\/24385\/"},{"hreflang":"de","url":"https:\/\/www.kaspersky.de\/blog\/gputhor-rowhammer-class-attack\/33868\/"},{"hreflang":"ru-kz","url":"https:\/\/blog.kaspersky.kz\/gputhor-rowhammer-class-attack\/31011\/"}],"acf":[],"banners":"","maintag":{"url":"https:\/\/www.kaspersky.com.br\/blog\/tag\/hardware\/","name":"hardware"},"_links":{"self":[{"href":"https:\/\/www.kaspersky.com.br\/blog\/wp-json\/wp\/v2\/posts\/25334","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=25334"}],"version-history":[{"count":1,"href":"https:\/\/www.kaspersky.com.br\/blog\/wp-json\/wp\/v2\/posts\/25334\/revisions"}],"predecessor-version":[{"id":25337,"href":"https:\/\/www.kaspersky.com.br\/blog\/wp-json\/wp\/v2\/posts\/25334\/revisions\/25337"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.kaspersky.com.br\/blog\/wp-json\/wp\/v2\/media\/25336"}],"wp:attachment":[{"href":"https:\/\/www.kaspersky.com.br\/blog\/wp-json\/wp\/v2\/media?parent=25334"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.kaspersky.com.br\/blog\/wp-json\/wp\/v2\/categories?post=25334"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.kaspersky.com.br\/blog\/wp-json\/wp\/v2\/tags?post=25334"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}