{"id":21345,"date":"2023-06-05T16:52:07","date_gmt":"2023-06-05T19:52:07","guid":{"rendered":"https:\/\/www.kaspersky.com.br\/blog\/?p=21345"},"modified":"2023-06-05T16:52:23","modified_gmt":"2023-06-05T19:52:23","slug":"transient-cpu-eflags","status":"publish","type":"post","link":"https:\/\/www.kaspersky.com.br\/blog\/transient-cpu-eflags\/21345\/","title":{"rendered":"Nova vulnerabilidade de hardware em processadores Intel \u00e9 detectada"},"content":{"rendered":"

Pesquisadores da Universidade de Maryland, nos EUA, e da Universidade de Tsinghua, na China, publicaram um artigo cient\u00edfico<\/a> documentando um novo m\u00e9todo de ataque de canal lateral que explora uma vulnerabilidade de hardware anteriormente desconhecida nos processadores Intel. Embora a vulnerabilidade pare\u00e7a afetar os processadores mais recentes do fabricante de chips, ela \u00e9 mais eficaz para atacar modelos mais antigos que tamb\u00e9m est\u00e3o expostos \u00e0 vulnerabilidade Meltdown<\/a>. O artigo provavelmente seria de interesse puramente cient\u00edfico, n\u00e3o fosse por um aspecto: os invasores roubam informa\u00e7\u00f5es confidenciais alterando os dados do registro de status<\/a>.<\/p>\n

Em portugu\u00eas, por favor<\/h2>\n

As vulnerabilidades do processador de hardware ligadas \u00e0 execu\u00e7\u00e3o especulativa de instru\u00e7\u00f5es t\u00eam sido objeto de muita pesquisa por mais de cinco anos<\/a>. Para simplificar ao m\u00e1ximo, todos os ataques propostos podem ser resumidos da seguinte forma: a CPU \u00e9 de alguma forma for\u00e7ada a ler dados aos quais o usu\u00e1rio n\u00e3o deveria ter acesso. Imagine este cen\u00e1rio te\u00f3rico: o programa do invasor n\u00e3o tem acesso \u00e0 chave de criptografia usada para proteger dados confidenciais. Se instruirmos a CPU a \u201cler a chave de criptografia em um determinado endere\u00e7o\u201d, a instru\u00e7\u00e3o simplesmente n\u00e3o ser\u00e1 seguida. A ajuda chega (ao invasor) na forma de execu\u00e7\u00e3o especulativa<\/a> de instru\u00e7\u00f5es \u2013 uma caracter\u00edstica importante das CPUs dos dias de hoje, que existe h\u00e1 quase tr\u00eas d\u00e9cadas: para acelerar, em vez de esperar que uma instru\u00e7\u00e3o termine, o processador executa a seguinte em paralelo.<\/p>\n

Se a primeira instru\u00e7\u00e3o verificar os direitos de acesso a informa\u00e7\u00f5es confidenciais, ela n\u00e3o deve, em teoria, permitir a execu\u00e7\u00e3o da instru\u00e7\u00e3o seguinte para ler essas informa\u00e7\u00f5es. Mas a\u00ed \u00e9 tarde demais: a seguinte instru\u00e7\u00e3o est\u00e1 sendo executada especulativamente. Observe que ainda n\u00e3o temos acesso a esses dados \u2013 mas a CPU tem. No caso de vulnerabilidades conhecidas, como Spectre<\/a>, os dados s\u00e3o carregados temporariamente no cache da CPU, mas n\u00e3o podem ser lidos assim. No entanto, podem ser lidos pelos canais laterais; por exemplo, executando repetidamente uma instru\u00e7\u00e3o \u2013 cujo tempo de processamento varia dependendo dos dados no cache. Repetir essa opera\u00e7\u00e3o muitas (milhares!) de vezes permite que os invasores recuperem dados apenas observando a rapidez ou a lentid\u00e3o com que algum comando aparentemente inofensivo \u00e9 executado.<\/p>\n

Percebemos que essa descri\u00e7\u00e3o \u201csimples\u201d ainda soa complicada. O novo artigo \u00e9 ainda mais desconcertante, especialmente porque os autores decidiram n\u00e3o perder tempo com uma descri\u00e7\u00e3o detalhada do ataque. O diagrama abaixo faz a descri\u00e7\u00e3o completa do caso:<\/p>\n

\"Vis\u00e3o<\/a>

Vis\u00e3o geral de execu\u00e7\u00e3o transit\u00f3ria de canal lateral temporal. Fonte<\/a>.<\/p><\/div>\n

Vamos tentar entender. EFLAGS \u00e9 um registrador de flags<\/em> no processador Intel que rastreia o status operacional da CPU. Ele pode armazenar<\/a> o resultado dos c\u00e1lculos, em particular se for igual a zero (o chamado zero flag ou ZF, em ingl\u00eas). Em seguida, vem a m\u00e1gica: imagine que um colega seu pense em um n\u00famero de 1 a 10 e seja instru\u00eddo a guard\u00e1-lo para si. Voc\u00ea continua chamando os n\u00fameros de 1 a 10 (procurando por quaisquer sinais que possam denunciar seu colega), mas ele n\u00e3o quer compartilhar a resposta correta e responde a cada vez com a palavra \u201ccris\u00e2ntemo\u201d. No entanto, quando voc\u00ea pronuncia o n\u00famero correto, ele demora um pouco mais para dizer \u201ccris\u00e2ntemo\u201d em compara\u00e7\u00e3o com outras vezes.<\/p>\n

Algo semelhante acontece neste novo ataque: realizamos in\u00fameros c\u00e1lculos com dados sens\u00edveis. Todos eles s\u00e3o feitos especulativamente. O resultado \u00e9 escrito no flag ZF (igual ou diferente de zero). N\u00e3o podemos saber diretamente o status desse sinalizador. Mas ent\u00e3o executamos uma instru\u00e7\u00e3o JCC um tanto in\u00fatil (especificamente a instru\u00e7\u00e3o JZ \u2013 \u201cjump if zero<\/em>\u201c), que roda um pouco mais devagar se a adivinharmos corretamente! E \u00e9 esse atraso mensur\u00e1vel na resposta que constitui a vulnerabilidade.<\/p>\n

N\u00e3o \u00e9 um problema (ainda)<\/h2>\n

O aspecto mais interessante desse ataque \u00e9 que ele n\u00e3o funciona sozinho. Para garantir que a execu\u00e7\u00e3o especulativa das instru\u00e7\u00f5es necess\u00e1rias seja poss\u00edvel, os bandidos precisam explorar mais uma vulnerabilidade. O artigo que estamos discutindo usa a vulnerabilidade Meltdown<\/a>, descoberta em 2018, que felizmente fornece acesso a informa\u00e7\u00f5es que est\u00e3o fora do alcance de pessoas leigas. Como resultado, dados confidenciais foram lidos com 100% de confiabilidade em todas as CPUs antigas afetadas por essa vulnerabilidade (o estudo usou um Intel Core i7 de sexta e s\u00e9tima gera\u00e7\u00e3o). Embora o experimento tenha falhado em CPUs de d\u00e9cima gera\u00e7\u00e3o, eles tamb\u00e9m experimentaram algum atraso ao executar uma determinada instru\u00e7\u00e3o do conjunto JCC.<\/p>\n

Na realidade, tipos de ataques ainda mais vers\u00e1teis, como o Spectre, que roubam informa\u00e7\u00f5es do cache da CPU, t\u00eam uma aplica\u00e7\u00e3o bastante restrita. Mas, pelo menos no caso deles, era \u00f3bvio que algo precisava ser feito: a probabilidade de um ataque avan\u00e7ado direcionado a dados cr\u00edticos era diferente de zero. Quanto ao novo artigo, estamos lidando mais com uma ideia de que, se funcionar, se aplica a processadores Intel mais antigos.<\/p>\n

Mas a not\u00edcia em si \u00e9 significativa: agora existe um novo mecanismo de canal lateral para extrair dados usando o status do registro de flag<\/em>. N\u00e3o se pode descartar que no futuro essa abordagem, combinada com alguma outra vulnerabilidade, tamb\u00e9m afetar\u00e1 as novas CPUs. Ou talvez tudo seja resolvido antes de vermos um novo ataque: afinal, a depend\u00eancia do tempo de execu\u00e7\u00e3o da instru\u00e7\u00e3o em rela\u00e7\u00e3o aos dados \u00e9 um problema bastante s\u00e9rio. Existe toda uma subdisciplina de criptografia que lida com a prote\u00e7\u00e3o de algoritmos de criptografia contra ataques de temporiza\u00e7\u00e3o<\/a>.<\/p>\n

De qualquer forma, a pesquisa sobre as especificidades das CPUs mais novas est\u00e1 em andamento. Felizmente, executar ataques a vulnerabilidades de hardware \u00e9 t\u00e3o dif\u00edcil quanto entend\u00ea-los. E, embora ainda n\u00e3o tenhamos visto nada que possa ser aplicado em grande escala, os especialistas de seguran\u00e7a da informa\u00e7\u00e3o em empresas que lidam com dados altamente confidenciais devendo levar em considera\u00e7\u00e3o essas amea\u00e7as e, no m\u00ednimo, monitorar sua evolu\u00e7\u00e3o.<\/p>\n\n","protected":false},"excerpt":{"rendered":"

Uma breve explica\u00e7\u00e3o em linguagem simples de um m\u00e9todo avan\u00e7ado de roubo de dados usando recursos das CPUs atuais.<\/p>\n","protected":false},"author":665,"featured_media":21346,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1119,1655,1656],"tags":[1790,3164,267],"class_list":{"0":"post-21345","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-cpu","11":"tag-processadores","12":"tag-vulnerabilidades"},"hreflang":[{"hreflang":"pt-br","url":"https:\/\/www.kaspersky.com.br\/blog\/transient-cpu-eflags\/21345\/"},{"hreflang":"en-in","url":"https:\/\/www.kaspersky.co.in\/blog\/transient-cpu-eflags\/25691\/"},{"hreflang":"en-ae","url":"https:\/\/me-en.kaspersky.com\/blog\/transient-cpu-eflags\/21110\/"},{"hreflang":"en-us","url":"https:\/\/usa.kaspersky.com\/blog\/transient-cpu-eflags\/28346\/"},{"hreflang":"en-gb","url":"https:\/\/www.kaspersky.co.uk\/blog\/transient-cpu-eflags\/25991\/"},{"hreflang":"es-mx","url":"https:\/\/latam.kaspersky.com\/blog\/transient-cpu-eflags\/26367\/"},{"hreflang":"es","url":"https:\/\/www.kaspersky.es\/blog\/transient-cpu-eflags\/28862\/"},{"hreflang":"ru","url":"https:\/\/www.kaspersky.ru\/blog\/transient-cpu-eflags\/35326\/"},{"hreflang":"x-default","url":"https:\/\/www.kaspersky.com\/blog\/transient-cpu-eflags\/48229\/"},{"hreflang":"fr","url":"https:\/\/www.kaspersky.fr\/blog\/transient-cpu-eflags\/20650\/"},{"hreflang":"de","url":"https:\/\/www.kaspersky.de\/blog\/transient-cpu-eflags\/30181\/"},{"hreflang":"ru-kz","url":"https:\/\/blog.kaspersky.kz\/transient-cpu-eflags\/26296\/"},{"hreflang":"en-au","url":"https:\/\/www.kaspersky.com.au\/blog\/transient-cpu-eflags\/31998\/"},{"hreflang":"en-za","url":"https:\/\/www.kaspersky.co.za\/blog\/transient-cpu-eflags\/31686\/"}],"acf":[],"banners":"","maintag":{"url":"https:\/\/www.kaspersky.com.br\/blog\/tag\/vulnerabilidades\/","name":"vulnerabilidades"},"_links":{"self":[{"href":"https:\/\/www.kaspersky.com.br\/blog\/wp-json\/wp\/v2\/posts\/21345","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=21345"}],"version-history":[{"count":3,"href":"https:\/\/www.kaspersky.com.br\/blog\/wp-json\/wp\/v2\/posts\/21345\/revisions"}],"predecessor-version":[{"id":21350,"href":"https:\/\/www.kaspersky.com.br\/blog\/wp-json\/wp\/v2\/posts\/21345\/revisions\/21350"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.kaspersky.com.br\/blog\/wp-json\/wp\/v2\/media\/21346"}],"wp:attachment":[{"href":"https:\/\/www.kaspersky.com.br\/blog\/wp-json\/wp\/v2\/media?parent=21345"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.kaspersky.com.br\/blog\/wp-json\/wp\/v2\/categories?post=21345"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.kaspersky.com.br\/blog\/wp-json\/wp\/v2\/tags?post=21345"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}