Relatórios recentes da imprensa falam sobre a mais nova descoberta de vulnerabilidade de segurança que envolvem ataques em recursos comuns a microprocessadores modernos (conhecidos como chips) responsáveis por alimentar nossos computadores, tablets, smartphones e outros dispositivos. Esses ataques, conhecidos como “Meltdown” e “Spectre”, estão recebendo uma enorme atenção devido a sua severidade. Há uma enorme preocupação da população em torno dessas vulnerabilidades, e é extremamente importante que sejam aplicadas todas as atualizações de software necessárias que foram cuidadosamente desenvolvidas e disponibilizadas pelos grandes fornecedores. Líderes em tecnologia, incluindo a Red Hat, estão trabalhando juntos para solucionar essas falhas e minimizar os riscos de potenciais ataques.

A equipe da Red Hat está trabalhando em mitigações a possíveis ataques com base nos embargos de segurança padrão do setor de TI. Essas mitigações estão sendo realizadas por equipes especializadas e focadas em criar conteúdos informativos a fim de preparar e manter o público atualizado com novas informações referentes a essas vulnerabilidades. Eu fui privilegiado em ser um dos responsáveis por liderar os esforços de mitigação do Meltdown e do Spectre, também conhecidos como variantes 1, 2 e 3 de uma família de ataques similares divulgados por meio do Project Zero do Google, em uma publicação feita em 3 de janeiro. Durante o processo de investigação, reproduzimos o Meltdown (variante 3) em nossos laboratórios e analisamos outras variantes enquanto trabalhávamos em colaboração com diversos parceiros de hardware em maneiras de evitar possíveis ataques.

Embora tenhamos um entendimento sólido dessas vulnerabilidades e das análises atuais sobre os fatores contribuintes a elas, bem como os patches para mitigação dos possíveis impactos, continuaremos o trabalho colaborativo com nossos parceiros, clientes e pesquisadores. Além disso, nosso objetivo é ajudar o público em geral a compreender esses problemas complexos por meio de uma linguagem e de termos que não requerem aos leitores uma profunda especialização ou conhecimento no assunto. Para aqueles que desejam detalhes técnicos mais aprofundados, a pesquisa original e publicações associadas estão disponíveis em http://meltdownattack.com/ e http://spectreattack.com/, no entanto, é válido ressaltar que muitos profissionais envolvidos em identificar essas falhas possuem larga experiencia em pesquisas acadêmicas voltadas para arquiteturas de computação. Incluindo profissionais com Ph.D. em área relacionada.  Portanto, não se sinta frustrado caso demorar um tempo maior para você realmente aprofundar nos detalhes técnicos. Esta é uma área bastante complexa e cheia de detalhes.

Para começar, explicaremos um pouco sobre a "execução especulativa" por meio de uma analogia baseada em nosso dia a dia.

Imagine que um cliente visite frequentemente a mesma cafeteria e pede sempre o mesmo tipo de café todas as manhãs. Com o passar do tempo, esse cliente passa a ser bem conhecido pelos atendentes, que se tornam familiares não só com o cliente mas também com suas preferências. Com o objetivo de oferecer um melhor atendimento e agilizar o tempo de espera do cliente, os atendentes decidem antecipar o pedido e preparar o café assim que o cliente aparece na porta da cafeteria. No entanto, um certo dia, o cliente decide pedir um café diferente do usual. Como o atendente já havia preparado o café antecipadamente, este terá de ser descartado e um novo café deverá ser preparado enquanto o cliente aguarda pelo pedido.

Levando essa analogia ainda mais adiante, imagine que os atendentes, sabendo o nome do cliente, escrevem o nome dele no copo usando um marcador permanente. Assim, de forma especulativa, além de prepararem o café usual, os atendentes também escrevem o nome do cliente no copo. Caso o cliente peça algo diferente do usual, o café preparado de forma especulativa deverá ser descartado juntamente com o copo. Entretanto, ao fazer isso, o nome do cliente juntamente com o conteúdo do copo fica visível a qualquer pessoa que esteja assistindo aquela cena.

Esse cenário da cafeteria envolve um trabalho de especulação. O atendente não tem certeza de que o cliente virá naquele dia ou que ele pedirá um café preto ou um café com leite, no entanto, com base no histórico desse cliente, o atendente decide antecipar o pedido para oferecer um melhor atendimento e evitar que o cliente fique aguardando na fila para ser atendido. Especulações similares acontecem todos os dias em nossas vidas, e na maioria das vezes essas especulações estão corretas e nos ajudam a economizar tempo. Com nossos computadores isso não é diferente.  Sendo assim, uma técnica conhecida como "execução especulativa" é utilizada para realizar certas operações de processos baseadas em suposições, antes mesmo de serem confirmados de que essas operações serão necessárias ou não. Na maioria das vezes, essas ações especulativas estão corretas e ajudam a economizar tempo.

No caso dos computadores, a execução especulativa é usada para decidir o que fazer quando colocado diante a um teste do tipo: "se A for válido, faça isso; do contrário, faça aquilo". Nós chamamos isso de condições de testes e, como resultado, o código que executa esses testes é parte do que chamamos de desvio condicional (conditional branch). Um desvio (branch) significa que uma porção de um determinado programa é escolhido para ser executado em resposta a qualquer resultado à condição validada. Chips de computação moderna possuem "previsões de desvios" (branch predictors) sofisticados que usam algoritmos elaborados para determinar qual resultado do teste condicional é provável de ser validado enquanto o teste ainda é calculado. Enquanto isso, de maneira especulativa, o código é executado no desvio que aparenta ser o mais provável. Caso a especulação esteja correta, o chip aparenta executar mais rápido do que quando espera-se pelo teste ser finalizado. Se a especulação estiver errada, o chip terá de descartar qualquer resultado especulativo e executar o outro desvio.  Em 99% das vezes, as previsões de desvio estão corretas em suas suposições.

Como você pode perceber, o benefício de desempenho alcançado quando um chip executa uma especulação de desvio de um código correto é altamente significativo. Sendo assim, pode-se dizer que a execução especulativa é sim uma das muitas otimizações que ajudaram a acelerar dramaticamente nossos computadores nas últimas décadas. Quando implementado corretamente, o benefício de desempenho alcançado é substancial. A fonte dos problemas recentemente descobertos vem da tentativa de otimizar ainda mais a arquitetura dos chips, assumindo que o processo especulativo é uma caixa preta completamente invisível aos olhos dos observadores externos (ou cibercriminosos).

A sabedoria convencional do setor acreditava que independente do que acontecer durante o processo de especulação (conhecido como "janela de execução especulativa"), os resultados ou eram confirmados e usados pelo programa, ou descartados completamente caso invalidados. No entanto, foi descoberto que existem meios que permitem que cibercriminosos tenham acesso ao que acontece durante a janela de especulação e, como resultado, eles conseguem manipular o sistema. É possível também que um cibercriminoso manipule o comportamento de previsões de desvio causando uma certa sequência de códigos a serem executados especulativamente, de uma forma em que normalmente ele nunca deveria ser executado. Acreditamos que essas vulnerabilidades e outras falhas similares são capazes de explorar a execução especulativa para gerar mudanças fundamentais na forma como os chips serão projetados no futuro. Isso permitirá que haja a execução especulativa, porém sem os riscos de segurança envolvidos.

Aprofundaremos um pouco mais nos ataques. Começando com o Meltdown (variável 3), o qual recebeu bastante atenção devido ao grande impacto causado. Nesta forma de ataque, o chip é enganado para carregar dados sensíveis durante a janela de especulação e assim, permitir que esses dados sejam visualizados mais tarde por pessoas não autorizadas. O ataque é baseado em uma prática comumente utilizada no setor, o qual separa os dados carregados em memória do processo de verificação de permissões. Novamente, a sabedoria convencional do setor opera baseado na suposição de que todo o processo de execução especulativa era realizado de maneira invisível e, portanto, ao separá-lo em porções não haveria qualquer risco de segurança.

No Meltdown, um desvio de código cuidadosamente elaborado é previamente organizado para executar algum código de ataque especulativo.  Esse código carrega alguns dados de segurança em um programa que geralmente não tem acesso. Devido ao fato desse processo acontecer de forma especulativa, a verificação para permissão de acesso acontecerá em paralelo (e sem falhar até o final da janela especulativa). Como consequência, um chip de memória interna especial conhecido como cache é carregado com esses dados privilegiados. Sendo assim, uma sequencia de códigos construídos de forma cuidadosa é usado para desempenhar outras operações de memória baseado nos valores dos dados privilegiados. Enquanto os resultados normalmente observados nessas operações não estão visíveis após a especulação (os quais são descartados), uma técnica conhecida como análise de canal lateral do cache pode ser usado para determinar o valor dos dados de segurança.

O processo de mitigação do Meltdown envolve a mudança de como a memória é gerenciada entre aplicativos de software e sistemas operacionais. Uma nova tecnologia introduzida, conhecida como KPTI (Kernel Page Table Isolation), separa a memória de uma maneira em que os dados de segurança não podem ser carregados em caches internos de chips enquanto o código de usuário estiver em execução. Ao adicionar novas etapas ao processo, todas as vezes que um aplicativo de software solicitar ao sistema operacional para realizar algo em seu favor (conhecido como "chamadas de sistemas"), isso causará um impacto no desempenho. O nível desse impacto no desempenho varia de acordo com a frequência que um aplicativo usa os serviços do sistema operacional.

O ataque Spectre é apresentado em duas partes. A primeira (variante 1) está relacionado com a violação “bounds check”.  Novamente, ao executar um código de forma especulativa, o chip poderá carregar algum dado que pode ser usado mais tarde para localizar um outro dado relacionado. Como parte da otimização de desempenho, o chip poderá fazer uma tentativa de carregar de forma especulativa um outro dado relacionado antes mesmo do primeiro ter sido validado dentro de um certo conjunto definido de valores. Se isso acontecer, é possível que o código seja executado de forma especulativa e tenha acesso a dados não autorizados no cache do sistema. Sendo assim, esses dados poderão ser extraídos com o uso de um ataque de canal lateral similar ao mencionado anteriormente.

Mitigar a primeira parte do Spectre envolve a adição do que chamamos de “load fences” em todo o kernel. Isso prevenirá a especulação do hardware de tentar desempenhar um segundo carregamento baseado na primeira tentativa. Para tanto, serão necessárias mudanças triviais e pequenas em toda a fonte do kernel. Particularmente, tais mudanças não causarão impactos no desempenho. Nossa equipe responsável pelas cadeias de ferramentas desenvolveu algumas ferramentas e trabalhou em colaboração com outras equipes para determinar onde essas load fences deverão ser localizadas.

A segunda parte do Spectre (variante 2) é, de alguma maneira, a mais interessante. Ela está relacionada em "treinar" o hardware de previsão de desvio a priorizar a execução especulativa de porções do código em vez de executar os códigos que deveriam estar sendo executados. Uma forma comum de otimizar o hardware é basear o comportamento de uma certa escolha de desvio na localização em memória do próprio código de desvio. Infelizmente, a maneira como essa localização da memória está armazenada não é única entre um aplicativo e o kernel do sistema operacional. Isso permite que previsões sejam treinadas para executar de forma especulativa qualquer código que o invasor desejar. Ao escolher cuidadosamente um “gadget” (código existente no kernel que tem acesso aos dados privilegiados), o invasor poderá carregar dados sensíveis nos caches dos chips, onde o mesmo tipo de ataque de canal lateral servirá para extraí-lo.

Um dos maiores problemas causados por essa segunda parte do Spectre é sua alta capacidade em explorar os limites entre o kernel do sistema operacional e um hipervisor, ou entre máquinas virtuais diferentes executadas no mesmo hardware subjacente. A previsão de desvio pode ser treinada por uma máquina virtual para causar códigos privilegiados no hipervisor (ou outra instância de máquina virtual) para acessar dados de um hipervisor confiável, que poderá ser usado para extrair dados por meio de um canal lateral. Isso gera riscos significativos aos ambientes de clouds públicas e privadas que executam servidores que ainda não receberam os patches.

Mitigar essa segunda parte do Spectre requer que sistemas operacionais (de forma seletiva) desativem a previsão de desvio do hardware sempre que um programa solicitar o sistema operacional (chamada do sistema) ou serviços do hipervisor. Dessa forma, qualquer tentativa feita por códigos maliciosos de treinar a previsão de desvio não será passada para o kernel do sistema operacional, hipervisor ou entre máquinas virtuais não confiáveis sendo executadas no mesmo servidor. Essa abordagem funciona muito bem. No entanto, isso gera um impacto significante no desempenho. Os patches da Red Hat, por padrão, implementam a mudança na segurança e aceitam o impacto no desempenho. No entanto, nós também daremos aos administradores de sistemas a capacidade de habilitar ou desabilitar essas e todas as outras configurações implementadas. Estamos trabalhando em parceira com toda a comunidade Linux para reduzir esse impacto ao longo do tempo ao examinar alternativas para desabilitar previsões de desvios. Uma possível alternativa é conhecida como “retpoline”, uma forma artificial de executar o código do kernel do sistema operacional que previne a especulação de desvio incorreta.

Esperamos que este artigo tenha ajudado você a ter uma melhor compreensão sobre esses ataques altamente sofisticados. A exploração desses ataques não são triviais e as mitigações são possíveis. Embora há exemplos on-line para o Meltdown (variante 3), grandes fornecedores, como a Red Hat, também estão disponibilizando patches por meio de atualizações do sistema operacional. É possível que novas vulnerabilidades relacionadas a esta possam surgir com o passar do tempo, e exemplos de como corrigí-los estarão disponíveis on-line. Portanto, é importante manter-se atualizado com as correções de segurança assim que elas se tornarem disponíveis.

É importante também ressaltar que esses são apenas os primeiros dias após a descoberta de uma nova classe de vulnerabilidades de segurança de sistemas e, como resultado, mitigações e orientações de práticas recomendadas associadas a elas podem mudar com o tempo e conforme a necessidade. Seguiremos com o trabalho em parceria com os líderes do setor e as comunidades open source para proteger nossos clientes dessas e de outras vulnerabilidades conhecidas, tornando o Linux cada vez mais robusto e seguro para prevenir ataques como Meltdown e Spectre. Durante os próximos meses, publicaremos mais informações sobre esse trabalho colaborativo e manteremos nossos clientes atualizados em relação a quaisquer novas orientações referentes as soluções da Red Hat. Para saber mais, visite https://access.redhat.com/security/vulnerabilities/speculativeexecution

Em destaque

Notícia do seu interesse em destaque