Tudo sobre os problemas Spectre & Meltdown

A ameaça e a resolução dos problemas de segurança Spectre & Meltdown, que estão praticamente em todos os CPUs atuais, dominam globalmente. Muito se tem falado nestes graves problemas... mas ainda pouco se explicou tecnicamente o que realmente está a acontecer.

Vamos explicar exatamente o que é o Spectre e o Meltdown e quais são os processadores realmente afetados.

Spectre & Meltdown - "Bomba relógio" e o seu preâmbulo colorido

Após lermos e ouvirmos tudo o que se falou sobre estes problemas, chegamos facilmente à conclusão que esta bomba estava "agendada" para vir a conhecimento público. Por outro lado o impacto poderia ser devastador se não existissem já medidas de mitigação previamente preparadas, minimizando assim o risco.

Era inevitável ser publicado muito por culpa das lacunas nos acordos de confidencialidade, porque alguns players desta indústria e da indústria da segurança, já têm conhecimento destas falhas há várias semanas.

Existe uma mistura muito “colorida” de informações sobre Spectre e Meltdown pelo mundo da world wide web. Enquanto todas as empresas de software e hardware estão cada vez mais focadas no desempenho e nas tentativas de solução, pouco parece interessar explicar convenientemente o que realmente se passa. Pese o facto de irmos aprofundar a explicação, dada a sua complexidade, muitos dos assuntos irão ser referidos com simplicidade para podermos entender. A par disto, sabemos também que muitos detalhes sobre ataques e contramedidas são deliberadamente mantidos em segredo e como tal, escondem alguma informação que não deve ser passada para o público em geral.

Specter & Meltdown: uma digressão pelo design dum CPU

Ao contrario do que tem vindo a ser publicado, Spectre e Meltdown não são "bugs" ou "vulnerabilidades", mas sim hacks (modificações) num sentido muito clássico.

O hardware e o software são criados para funcionar sem erros, conforme o objetivo das empresas que os desenvolveram. Para lá do modo de operação especificado e pensado, este binómio oferece possibilidades que até mesmo as pessoas que os criaram desconhecem. Assim é com estes hacks. Esta "habilidade" foi criada para permitir que os atacantes epigrafem e, de seguida, leiam os dados alocados em tempo real na memória do seu computador.

Supostamente, e de acordo com o fluxo nominal do programa, a leitura destes dados, não deveria ser possível. Parece complicado? Sim é complicado, vamos tentar descomplicar.

Problema de Segurança Nr. 1: Out of Order

Os CPUs modernos usam vários ciclos do relógio (Mhz) para computação, portanto, existem latências entre as instruções sucessivas. Desde o primeiro Pentium da Intel, quase todos os CPUs x86 funcionam “fora de ordem” (OoO), para reduzir o tempo de espera. Isso significa, ao contrário do que muita gente pensa, são os próprios processadores e não o software, que decidem a ordem de processamento dos comandos. Estes podem preferir ou evitar tarefas individuais de modo a aproveitar todo o poder computacional existente no mesmo.

Problema de Segurança Nr. 2: Speculative Execution

A execução especulativa é utilizada quase que sinonimamente. Esta extensão usa praticamente todos os CPU’s com a funcionalidade de OoO.

Equipados com uma unidade de previsão (salto), eles não podem apenas executar comandos já comissionados, mas também executar entradas especulativas no código do programa. Novamente, o CPU decide quais instruções que provavelmente serão chamadas a seguir, com base em análises relativamente primitivas.

Se a execução especulativa tivesse que esperar por informações complexas e processos do sistema que eram muito lentos, não traria nenhuma vantagem de velocidade. Dentro do fluxo nominal do programa, esse também não é um problema. Se uma instrução não for chamada mais tarde, o processador descarta o resultado sem que o software o venha sequer a descobrir. Basicamente o software não sabe nada sobre todo o processo. Por outro lado, se a previsão estiver correta, o CPU simplesmente "calcula" o resultado desejado do ponto de vista do processo a uma taxa inusitadamente rápida.

Problema de Segurança Nr. 3: Privilege Levels

A divisão de memória é uma característica do sistema operativo na qual o CPU não tem qualquer influência. Especificamente, cada processo opera no próprio espaço do seu endereço virtual e sem contacto direto com outros programas quando executa o sistema operativo. Isso separa parte do espaço de endereço virtual de cada processo para os seus próprios fins, o chamado espaço do kernel (núcleo).

Por sua vez, o programa só pode funcionar na sua própria parte, chamado de User-space (espaço de utilizador). Se um User-space necessitar de usar dados exteriores ao mesmo, ele deve solicitá-lo via syscall (chamada de sistema) no sistema operativo e aguardar a entrega desses dados.

Este mecanismo de segurança é implementado no CPU por meio do nível de privilégio. Para certos comandos em particular, o acesso a dados protegidos no espaço do kernel, o CPU necessita em primeiro lugar de ser autorizado pelo sistema operativo, para o uso do modo mais privilegiado.

Assim, um processo no User-space, nunca pode nominalmente obter acesso aos dados fora dele, desde que o sistema operativo não o ajude nesta tarefa. Se tentar fazê-lo, a violação de nível de privilégio é registada e o sistema operativo pode encerrar o processo antes de receber os dados solicitados. Pelo menos é assim que tudo funciona na teoria.

Problema de Performance: Caching

Os carregamentos, mais conhecidos como “Loading”, são uma causa comum de longas latências nas instruções e é por isso que os computadores modernos querem evitá-las ao máximo com o armazenamento temporário e rápido de dados chamados de cache.

Depois dos dados passarem pelas memórias RAM (Random Access Memory), estas seguem para os caches L3, L2 e L1 dos CPUs.

As caches nos CPUs são extremamente rápidas, mas igualmente dispendiosas e por isso bem mais pequenas que os vários gigabytes da memória principal. Enquanto os caches L3 têm alguns megabytes, os caches de nível L2 e consequentemente de nível L1 têm apenas alguns kilobytes.

A regra geral é no fundo: quanto mais pequeno um cache for mais rápido é a performance do mesmo.

Geralmente o cache L1 encontra-se imediatamente ao lado das unidades de computação e diminui substancialmente a carga administrativa das mesmas. Ao mesmo tempo, somente alguns fragmentos dos dados ou programas podem ser mantidos nestes mesmos caches. Mais uma vez, o processador decide quais são esses fragmentos. Uma análise de segurança pelo sistema operativo tornaria todos este caches ineficazes, uma vez que estes dependem dos dados armazenados na memória principal.

Acesso Nr. 1: Meltdown

Este é a ataque mais vigiado até ao momento e apenas comprovado nos processadores da Intel. Entre outras coisas, os CPUs da Intel, executam na memória especulações antes de estes serem chamados por um processo e também antes de completar uma verificação ao nível de privilégio. Isto significa que os acessos ao espaço do kernel também podem ser realizados de forma especulativa, mesmo que o código do programa pertença a um processo no user-space.

Quando um atacante garante que o programa lógico nunca lança ativamente as instruções para o mesmo, esse nunca será encontrado, nem durante a monitorização de privilégios, porque, o processador simplesmente descarta as instruções, supostamente indesejadas, na qual do ponto de vista do software, a segurança de dados esta garantida.

No entanto, há uma exceção para isto ao nível do processador. O acesso à memória indireta chama um endereço de memória específico dependendo de outro valor, por exemplo, um fragmento de dados específico no user-space (dependendo do valor de um bit no espaço do kernel).

Neste caso, o bit inacessível é usado apenas internamente pelo CPU e também o resultado do processo de carregamento iniciado é descartado novamente após a deteção de uma especulação errada. Neste caso, um acesso de leitura no user-space foi impedido, mas durante uma execução especulativa, o sistema de cache também capturou o fragmento de dados e gravou o mesmo para o uso num “legitimo” futuro.

Acesso Nr. 2: Spectre

O segundo ataque também visa em permitir o acesso ilegítimo de dados no cache antes de ser descartado, mas, ao contrário do Meltdown, o Spectre não funciona no seu próprio espaço de endereços e tenta a fusão entre o espaço do kernel e o user-space e isto, somente, com processos exóticos. Estes processos exóticos também realizam regularmente vários tipos de acessos à memória para endereços permitidos. Neste processo, a intenção passa igualmente, em acelerar o uso especulativo do CPU. O último não tem tempo para distinguir entre os processos atualmente em execução e em prol do desempenho, descarta o que não é desejável. Isto acontece porque muitas operações que podem beneficiar da mesma otimização, são executadas em programas diferentes.

Após os primeiros passos, o Spectre recria fragmentos de código do processo atacado no seu próprio user-space. Este usa esses fragmentos para treinar a previsão de salto de um alvo interessante para o atacante. Mais tarde, quando o processo de destino inicia a cópia do código, a previsão de salto treinada, realizará erradamente, uma execução especulativa com base nos parâmetros treinados pelo atacante. Este método, pode agora ser usado novamente, para iniciar padrões de carregamento específicos, independentemente das informações inatingíveis. Simplificando:

Spectre 1 (A mais simples): Ultrapassar as verificações de segurança do próprio alvo e permitir que as instruções subsequentes relacionadas à segurança, sejam executadas de forma especulativa e de forma abusiva.

Spectre 2 (A mais complexa): Provocar um salto indireto para qualquer instrução de carregamento desejado pelo atacante.

Benchmarks malignos

No primeiro passo, tanto o Meltdown como o Spectre só provocaram acesso a um bit inatingível que resultou num carregamento específico. Estes dados também são nominalmente inacessíveis porque a gestão do cache é exclusivamente controlada no CPU e incompreensível para o software. Já há algum tempo que se conhecem métodos do modo nominal de operações, que, contornam essa restrição. Esses são os chamados, ataques de canais laterais. Em princípio, esta designação inclui, todas as ações de espionagem que não fazem parte de uma sequência de um programa, independentemente se este é desejado ou malware.

O Spectre e Meltdown exploraram o propósito inerente dos caches. Os fragmentos de dados usados ​​pelas instruções anteriores não precisam de ser carregados a partir da memória “lenta” chamada de RAM. Reconstruir acessos anteriores aos dados, medindo sistematicamente a velocidade de acesso onde estes foram armazenados em cache anteriormente, é relativamente fácil. Em Meltdown, o atacante pode reconstruir facilmente o bit alvo, uma vez que este sabe qual o valor do bit de destino que aponta para o seu user-space.

Os ataques de Spectre são mais complexos e têm obrigatoriamente que conhecer uma estrutura de dados, além do fluxo do programa alvo. Neste caso quer o atacante, quer o alvo, têm acesso de leitura aos dados roubados.

Quais são os perigos do Spectre e Meltdown?

Em primeiro lugar, a boa notícia. Ambos os tipos de ataques só têm acesso de leitura e não podem manipular dados, criptografar discos rígidos ou assumir o controlo dos computadores, mesmo que a informação lida possa facilitar outros ataques. Este é apenas um pequeno consolo para a grande maioria dos computadores nos quais os dados de acesso, como palavras-chave ou acesso a dados bancários são introduzidos. Quer este seja diretamente introduzido, armazenado num browser ou num software que gere as palavras chave se acesso, todos os dados que podem ser lidos num PC ou num servidor, podem potencialmente ser intercetados.

Quais cenários de aplicação são afetados?

O Meltdown tem uma importância bastante menor a médio prazo. O ataque de um processo do user-space para o espaço no kernel é um processo, que somente visa o sistema operativo de modo a que contramedidas apenas são tomadas num único ponto.

O oposto acontece com o Spectre. Embora o ataque tenha que ser especificamente personalizado para o processo de destino, qualquer outro programa que seja calculado no mesmo CPU, pode ser o alvo.

O Spectre funciona independentemente de qualquer camada intermediária de isolamento. O recipiente, por exemplo a sandbox de um browser é igualmente ineficaz quanto a separação de máquinas virtuais, como num servidor na cloud.

Existe hardware seguro?

Os ataques afetam todos os processadores com execução especulativa e com caches. O último está presente em todos os CPUs e a execução especulativa praticamente em todos.

As exceções, são as arquiteturas Itanium da Intel, os modelos UltraSPARC originais produzidos pela Sun (mas não todos os outros derivados SPARC) e a primeira geração dos Atom da Intel produzidos antes de 2013. Estes funcionam com in-order-pipelines mais simples e de baixo desempenho. Servem igualmente como exemplo das desvantagens destas arquiteturas. No entanto, eles são os únicos processadores seguros 100% para o Spectre, em aplicações típicas x86. Todos os outros representantes x86 desde o primeiro Intel Pentium, incluindo os x86-64, estão afetados. Mas há diferenças.

A Intel e AMD, utilizaram a execução especulativa para melhorar o desempenho. No entanto a nova arquitetura da AMD usada nos CPUs para Desktop, Ryzen e nos CPUs para servidores Epyc, não permitem certas execuções como em modelos anteriores ou como em quase todos os modelos da Intel.

O porquê disto ser assim é explicado mais em baixo. Numa escala de zero a dez pode-se dizer de momento, que o grau de risco dos novos CPU da AMD é de 1 e da Intel de 9. Esta informação foi obtida por uma empresa que já correu mais de 36 mil testes nas ultimas semanas, em mais de 6000 sistemas com CPUs Epyc e Opterons da AMD, Power 9 da IBM, Sparc M8 e Xeons E7 e E5 da Intel.

Até mesmo CPUs mais antigos da AMD detêm nessa escala um valor de risco pouco superior a atual arquitetura. No entanto, é possível, mesmo com Ryzen ou Epyc, ter acesso direto a memória, desde que, se tenha acesso direto ao hardware e que a instalação do Windows seja feita com o método tradicional usando o Master Boot Record (mbr) em Instalações do Windows mais antigas, em vez de UEFI. No último caso seria necessário inicializar um outro hack no MBR (Master Boot Record ou Registro Mestre de Inicialização) do disco para tornar isto tudo possível.

Visto que os novos Ryzen e Epyc só têm suporte direto da AMD quando usando o sistema operativo Windows 10 ou a versão equivalente para Servidores, leva com que o anteriormente mencionado não se aplique. Esta é a verdadeira razão pela qual a AMD continua a comunicar “Near Zero-Risc”.

Potencialmente afetados também são a maioria dos processadores para outros conjuntos de instruções. O PowerPC da IBM, conhecido nos servidores e computadores antigos da Apple, bem como os designs de núcleo mais potentes da ARM, que estão instalados em todos os smartphones da Apple, Samsung, Huawei entre outros.

Mesmo CPUs exóticos com um conjunto de instruções de código aberto como o RISC-V pode ser afetado. Mas aqui é revelada uma pequena informação com alto grau de interesse. Embora existam processadores RISC-V integrados com arquitetura OoO, estes não podem realizar acessos de memória especulativos e portanto, são considerados seguros. Mesmo com outros dos processadores acima mencionados, é incerto até que ponto as suas opções de OoO vão.

Cada novo CPU da AMD e Intel promete uma previsão de salto melhorada para um uso mais eficiente fora da ordem (OoO), mas os detalhes técnicos por trás do aumento no desempenho são segredos comerciais. Durante muito tempo, estas unidades de controlo foram muitas vezes maiores do que os núcleos de computação reais.

No Ryzen até se falou sobre inteligência artificial e estruturas neurais. Os atacantes precisariam de fazer uma engenharia reversa desses princípios funcionais antes que estes possam criar e iniciar um ataque bem-sucedido. A implementação do exemplo Meltdown funciona bem nos atuais CPUs da Intel, mas falha com AMD e ARM.

O Porquê, não é discutido publicamente, mas presumivelmente para tornar a vida dos invasores mais difícil. Por outro lado, com base nas informações disponíveis, nem podemos estimar o quão grande é o risco para as gerações mais antigas da Intel com uma unidade diferente deste Out-of-Order que a semanas se tornou publico.

Como são os ataques?

Uma vez que o código malicioso foi instalado num sistema, ele ainda tem um longo percurso pela frente. A execução necessita de algumas dúzias ou centenas de ciclos de clock e mesmo a avaliação do cache requer numerosas instruções para reconstruir um único bit. No entanto, os ataques de Spectre extraem até 10 KB por segundo da aplicação de destino, com Meltdown são possíveis até 500 KB por segundo.

Essas são, reconhecidamente, velocidades com as quais ninguém trabalhou desde a eliminação das unidades de disquete, mas tanto Spectre como o Meltdown têm uma peculiaridade. Ambos não são identificáveis ​​pelos sistemas operativos ou pelos softwares de segurança, já que as instruções do processo são legítimas. Um invasor pode portanto, passar despercebido por qualquer sistema de segurança como por exemplo o antivírus entre outros, durante um período ilimitado de tempo. Apesar da largura de banda, não ser suficiente para transmitir todas as operações do sistema, uma busca sistemática de programas que contenham, usam ou gerenciam senhas, não é um problema.

Este artigo servirá de base para novas atualizações e para uma discussão técnica e prática, mas, a última palavra sobre o Spectre e Meltdown só será provavelmente escrita daqui a alguns anos.