Ataque Downfall

 (downfall.page)
1 pontos por GN⁺ 2023-08-09 | 1 comentários | Compartilhar no WhatsApp
  • Vulnerabilidade CVE-2022-40982 em processadores Intel amplamente usados em computadores pessoais e na nuvem, permitindo roubar dados de outros usuários que compartilham o mesmo computador
  • O ponto central da falha é que a instrução Gather, durante a execução especulativa no processo de otimização de memória, expõe o conteúdo interno do arquivo de registradores vetoriais
  • O ataque é implementado com as técnicas GDS e GVI e, nas demonstrações, mostrou vazamentos além das fronteiras de isolamento, incluindo chaves AES, dados do Linux Kernel e até monitoramento de caracteres imprimíveis
  • O impacto vai do Intel Core de 6ª geração Skylake até a 11ª geração Tiger Lake, e usuários de nuvem podem ser afetados mesmo sem possuir diretamente um dispositivo Intel
  • A atualização de microcódigo da Intel bloqueia os resultados transitórios do Gather, mas algumas cargas de trabalho podem sofrer até 50% de overhead após a mitigação

A vulnerabilidade visada pelo Downfall

  • Downfall mira uma falha crítica em processadores modernos usados em computadores pessoais e na nuvem
  • A vulnerabilidade é identificada como CVE-2022-40982
  • Ela permite acessar e roubar dados de outros usuários que compartilham o mesmo computador
    • Um app malicioso baixado da app store pode roubar informações sensíveis como senhas, chaves de criptografia, dados bancários, e-mails pessoais e mensagens
    • Na nuvem, um cliente malicioso pode roubar dados e credenciais de outros clientes que compartilham a mesma máquina na nuvem

Causa técnica da vulnerabilidade

  • Um recurso de otimização de memória dos processadores Intel expõe involuntariamente registradores internos de hardware ao software
  • Isso permite que software não confiável acesse dados de outros programas aos quais originalmente não deveria ter acesso
  • A instrução Gather, usada para ler mais rapidamente dados espalhados na memória, vaza conteúdo interno do arquivo de registradores vetoriais durante a execução especulativa
  • As técnicas Gather Data Sampling (GDS) e Gather Value Injection (GVI) são usadas para explorar isso
  • Os detalhes técnicos estão resumidos no artigo do Downfall

Casos de vazamento confirmados em demonstrações

  • As demonstrações do Downfall mostram que dados sensíveis podem vazar através de diferentes fronteiras de isolamento
    • Video 7: roubo de chaves AES de 128-bit e 256-bit de outro usuário
    • Video 8: roubo de dados arbitrários do Linux Kernel
    • Video 9: monitoramento de caracteres imprimíveis

Sistemas afetados e condições do ataque

  • Os dispositivos afetados são equipamentos baseados em processadores Intel Core da 6ª geração Skylake até a 11ª geração Tiger Lake
  • Uma lista mais abrangente de processadores afetados será fornecida pela Intel na lista de affected processors
  • Mesmo sem possuir um dispositivo físico baseado em Intel, usuários de nuvem podem ser afetados
    • A participação da Intel no mercado de servidores é superior a 70%
  • O atacante pode mirar credenciais de alto valor, como senhas e chaves de criptografia
  • O roubo de credenciais pode ir além de uma quebra de confidencialidade e levar a outros ataques que prejudiquem a disponibilidade e a integridade do computador
  • O GDS é relativamente fácil de transformar em ataque real
    • Foram necessárias 2 semanas para desenvolver um ataque end-to-end que rouba chaves de criptografia do OpenSSL
    • Basta que atacante e vítima compartilhem o mesmo núcleo físico do processador
    • Em computadores modernos com multitarefa preemptiva e multithreading simultâneo, esse compartilhamento acontece com frequência

Fronteiras de isolamento, SGX e impacto em navegadores

  • Downfall também afeta fronteiras de isolamento comuns
    • máquinas virtuais
    • processos
    • isolamento usuário-kernel
  • Intel SGX também é afetado
    • Intel SGX é um recurso de segurança em hardware das CPUs Intel para proteger dados do usuário contra software malicioso
  • A exploração remota via navegador web é teoricamente possível
    • Na prática, ainda são necessárias pesquisas e trabalho adicional de engenharia para demonstrar um ataque bem-sucedido no navegador

Tempo de exposição e dificuldade de detecção

  • Os usuários ficaram expostos a essa vulnerabilidade por pelo menos 9 anos
    • Os processadores afetados existem desde 2014
  • Os ataques Downfall são difíceis de detectar
    • Sua execução se parece em grande parte com a de aplicativos normais
    • Em teoria, seria possível criar um sistema que use contadores de desempenho de hardware para detectar comportamentos anormais, como excesso de cache misses
    • Softwares antivírus comerciais comuns não conseguem detectar esse ataque

Mitigações e overhead de desempenho

  • A Intel distribuiu uma atualização de microcódigo
    • Essa atualização bloqueia os resultados transitórios da instrução Gather
    • Ela impede que o código do atacante observe dados especulativos produzidos pelo Gather
  • O overhead da mitigação varia conforme a presença do Gather no caminho crítico de execução do programa
  • Segundo a Intel, algumas cargas de trabalho podem sofrer até 50% de overhead
  • Não é seguro desativar a mitigação só porque a carga de trabalho não usa Gather
    • CPUs modernas usam registradores vetoriais para otimizar tarefas comuns, como cópia de memória e troca de conteúdo de registradores
    • Nesse processo, dados podem vazar para código não confiável que explore o Gather

Cronograma de divulgação e código de reprodução

  • A vulnerabilidade ficou sob embargo por quase 1 ano
  • Ela foi reportada à Intel em 24 de agosto de 2022
  • Downfall foi apresentado em 9 de agosto de 2023 na BlackHat USA e em 11 de agosto de 2023 no USENIX Security Symposium
  • O código de reprodução está disponível no GitHub POC

Pontos de atenção para outros projetistas de processadores

  • Outros processadores também têm memória SRAM compartilhada dentro do núcleo, como arquivo de registradores de hardware e fill buffer
  • Fabricantes precisam projetar com mais cuidado unidades de memória compartilhada para evitar vazamento de dados entre diferentes domínios de segurança
  • Também é necessário investir mais em verificação e testes de segurança

Nome e vulnerabilidades relacionadas

  • O nome Downfall vem da ideia de derrubar a maioria das fronteiras básicas de segurança dos computadores
  • Downfall pode ser visto como sucessor de vulnerabilidades anteriores de vazamento de dados em CPU, como Meltdown e Fallout
  • Nesse contexto, Downfall volta a contornar mitigações anteriores

Recomendações de fornecedores e documentação técnica

Leituras relacionadas

1 comentários

 
GN⁺ 2023-08-09
Opiniões no Hacker News

  • Mesmo depois do ataque Spectre inicial, parece estranho esse padrão em que pesquisadores externos continuam encontrando ataques parecidos e os fabricantes de chips corrigem depois
    Em princípio, os fabricantes de chips são especialistas em execução especulativa, sabem exatamente como o chip funciona e têm suítes de validação, simuladores e até especificações internas legíveis por máquina, então deveriam estar na posição mais favorável para descobrir isso
    Pesquisadores externos precisam explorar uma caixa-preta e fazer engenharia reversa com materiais muito piores, como patentes, mas, mesmo anos depois, indivíduos ou grupos externos ainda encontram essas vulnerabilidades
    Antes do Spectre, talvez não tivessem considerado esse vetor de ataque, mas, depois que o mecanismo geral foi revelado, não seria de esperar que os fabricantes de chips reunissem suas pessoas mais brilhantes e dissessem: “vasculhem tudo e encontrem outros ataques do tipo Spectre”?
    Talvez eles já saibam de tudo, mas estejam enterrando o assunto na esperança de que não venha a público, para evitar constrangimento e perda de desempenho

    • Pode ser viés de sobrevivência. Não dá para saber quantos bugs do tipo Spectre foram corrigidos sem divulgação pública
    • Esse raciocínio me parece desconfortável. Com a mesma mentalidade, um programador que cometeu dois erros de segurança de memória também poderia ser presumido mal-intencionado, e não apenas alguém que cometeu erros humanos
      Se algo é usado por bilhões de pessoas, acho que elas vão encontrar mais problemas, defeitos e exploits do que quem o criou. O simples fato de esses problemas existirem não sustenta nem refuta conclusões adicionais sobre o motivo
    • Uma possibilidade que ninguém mencionou ainda é que os fornecedores de chips talvez não invistam muito tempo em encontrar esse tipo de coisa porque, na prática, ela não é tão importante
      Pesquisadores de segurança têm incentivo para encontrar algo e construir reputação. Muitas vezes afirmam que algo é uma vulnerabilidade de segurança capaz de abalar o mundo, mesmo quando não tem grande significado para atacantes reais
      Ataques de execução especulativa já foram encontrados em ambientes reais? Talvez não. Se for assim, há pouco motivo para um fornecedor de chips gastar uma fortuna nisso
      Clientes reais não sofrem prejuízo, exceto quando um pesquisador externo força uma ação e acaba levando à publicação de um novo microcódigo que reduz o desempenho
      Também vale notar que as mitigações para esses ataques sempre vêm com uma chave para desligá-las. Isso não é algo comum em correções de segurança, e em muitos casos é porque esses ataques não são muito importantes
      Softwares rodando no mesmo núcleo físico ou na mesma CPU física têm o mesmo nível de confiança, ou são isolados em sandbox com força suficiente para impedir que o ataque seja executado
    • Pode ser um caso da lei de depuração de Kernighan. “Todo mundo sabe que depurar é duas vezes mais difícil do que escrever um programa inicialmente. Então, se você o escreve da forma mais inteligente possível, como vai conseguir depurá-lo?”
      A Intel sem dúvida torna seus chips “tão inteligentes quanto possível” e, portanto, por definição, eles não podem ser totalmente depurados
    • Falando como engenheiro de CPU, o Spectre revelou um canal de vazamento de informação que antes não era considerado vulnerável. Por isso surgiram novos exploits em sequência; no centro deles havia uma nova ideia, e outras pessoas construíram em cima dela
      Também é importante notar que isso não são bugs. O projeto está funcionando como pretendido. Sabíamos que o desempenho da CPU variava conforme o código executado anteriormente, e isso foi aceito porque se julgou que o custo das alternativas em termos de energia, desempenho e área seria alto demais. Isso é engenharia: pesar alternativas e escolher
      Neste caso, conforme a CPU ficou rápida o bastante, uma pequena fração de bit por iteração se tornou largura de banda explorável por um ataque, mas alguém precisava demonstrar isso para que o setor entendesse. Foi isso que mudou o julgamento de engenharia

  • O link do artigo da Intel está quebrado, e o link correto parece ser este: https://www.intel.com/content/www/us/en/developer/articles/t...
    Como observação geral, ainda há muitas nuvens que rodam cargas de trabalho de usuários diferentes no mesmo núcleo físico? Eu achava que a maioria tinha mudado seus schedulers alguns anos atrás para impedir vazamentos entre domínios entre hyperthreads
    A afirmação de que isso afeta todos os usuários da internet parece um exagero enorme. Também não vi um exploit baseado em navegador e, mesmo que existisse, afetaria apenas um número minúsculo de usuários visados. Já se passaram vários anos desde o Spectre, e fico me perguntando se algum ataque de execução especulativa já foi encontrado em ambiente real
    O mais interessante é que esses bugs de execução especulativa continuam parecendo passíveis de correção via microcódigo. Quando apareceram pela primeira vez, havia o medo de que talvez fosse preciso descartar e substituir chips físicos em massa, mas será que isso alguma vez foi realmente necessário?
    Até onde sei, todos os bugs puderam ser mitigados com uma combinação de mudanças de software e microcódigo, em alguns casos pagando apenas algum custo de desempenho. Nenhum bug exigiu silício novo. A exceção talvez sejam casos como as primeiras versões do AMD SEV, que foram de fato escapadas de forma impossível de corrigir

    • Fora as grandes nuvens como AWS/GCP/Azure, há uma quantidade enorme de provedores de VPS, e ali a resposta é “sim”. Mesmo lugares que vendem cores “dedicados” muitas vezes querem dizer apenas que dão uso ilimitado de CPU
    • Ataques Spectre precisaram ser corrigidos no kernel e reduziram bastante a velocidade de execução de CPUs Intel: https://www.notebookcheck.net/Spectre-v2-mitigation-wreaks-h...
    • As instâncias t da AWS não servem justamente para esse propósito? Eu entendia que elas eram “compartilhadas” no nível do core; se não fossem, não haveria motivo para existir um conceito como saldo de créditos de CPU
    • Acho que a maioria, talvez quase todas as VMs de nuvem, recebe cores dedicados
      Claro, há casos compartilhados como a série T da AWS, e outras nuvens devem ter algo parecido, mas imagino que seja possível inserir “flushes” adicionais entre usuários para impedir vazamentos entre tenants
      Naturalmente, vazamento entre processos dentro de um único tenant é um problema tanto na nuvem quanto on-premises e, no fim, é preciso decidir o quanto você confia que os processos na sua própria máquina não vão se tornar maliciosos
    • Disseram que isso poderia afetar “todo mundo na internet” porque a maioria dos servidores é vulnerável

  • Executar código de domínios de segurança diferentes no mesmo núcleo físico de processador parece impossível de fazer direito, e acho que já está na hora de parar com isso
    Os casos comuns são basicamente dois: VMs e JavaScript
    VMs precisam ser abandonadas. É preciso dedicar certos cores a certas VMs, ou pelo menos a certos clientes
    JavaScript é um pouco mais difícil
    De qualquer forma, não se deve abrir mão de desempenho no caso geral

    • Sobre JavaScript, “vamos simplesmente parar” parece uma boa
    • Há aqui uma oportunidade de marketing para recolocar multicore no centro. A maioria das cargas de trabalho já chegou ao ponto de retornos decrescentes ao adicionar mais cores à CPU, mas, se a conclusão for que precisamos de mais cores para rodar com segurança mais processos simultâneos ou abas de navegador, poderemos ver chips de notebook com 128 cores
    • Há algum tempo me pergunto se faz sentido dividir a CPU em “IOPU” e “SPU”
      A IOPU ficaria encarregada de comandar o restante do hardware do sistema e não precisaria ter desempenho muito alto
      A SPU seria otimizada para código escalar que precisa rodar rápido e para código com muitas ramificações
      A SPU precisaria apenas de segurança mínima, algo como impedir a leitura de memória arbitrária ao buscar dados da RAM. Como apenas um programa roda por vez, execução especulativa não seria um problema
      No meu sistema, quase não há programas que precisem de muita capacidade de processamento e, mesmo quando precisam, é de forma intermitente, então acho que não haveria muitas trocas de tarefa na SPU
    • Exato. Esse modelo já passou do auge. Foi a era dos sistemas de tempo compartilhado, dos anos 1960 aos 1990, quando vários usuários tinham contas shell em sistemas Unix de universidades ou ISPs
      Esses ataques de CPU mostram que um sistema seguro de tempo compartilhado em que usuários executam código de máquina arbitrário já não é mais realista
      O tempo compartilhado ainda vai existir em casos em que as pessoas confiam umas nas outras, como colegas do mesmo projeto compartilhando uma máquina de build
    • É parecido com a segunda lei da termodinâmica antes de a mecânica estatística aparecer e colocá-la em ordem. Talvez ela não fosse fundamentada de modo analítico e filosófico sólido, mas experimentalmente era tão robusta que qualquer um tentando vender o contrário pareceria extremamente suspeito
      A ideia de que é possível impedir que dois programas executados em um computador espionem um ao outro está nesse mesmo nível

  • Aviso de segurança da Intel: https://www.intel.com/content/www/us/en/developer/articles/t...
    Merge no kernel Linux: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

  • Como o impacto vai só até a 11ª geração, não parece que essa vulnerabilidade tenha sido divulgada à Intel cedo o bastante para ser corrigida na 12ª geração. Então fico pensando se ela acabou sendo resolvida por acaso ao corrigirem outra coisa
    Pelo artigo, “a Intel afirmou que CPUs mais recentes como Alder Lake, Raptor Lake e Sapphire Rapids não são afetadas. No entanto, isso parece ser mais um efeito colateral de uma arquitetura bastante alterada do que uma consideração de segurança”
    No fim, foi corrigido aleatoriamente ou, pelo menos, este exploit específico deixou de funcionar

    • O comportamento microarquitetural muda a cada geração e, portanto, os efeitos colaterais também mudam. Tanto corrigir um problema por acaso quanto criar um novo problema por acaso acontece com relativa frequência

  • Segundo o FAQ, os usuários ficaram expostos a essa vulnerabilidade por pelo menos 9 anos, já que os processadores afetados existem desde 2014
    É surpreendente que vulnerabilidades como essa passem despercebidas por anos e, então, alguém leve só duas semanas para codificar um exploit

    • Para começo de conversa, o tempo para encontrar a vulnerabilidade provavelmente foi muito maior que duas semanas
    • O fato de ela ter sido divulgada só significa que um pesquisador white hat ou grey hat encontrou a vulnerabilidade. Não há como saber se, nesse meio-tempo, alguém menos escrupuloso explorou a mesma falha, nem quantas vezes
    • É bem provável que o trabalho tenha sido baseado em exploits anteriores

  • Referência no LWN: https://lwn.net/Articles/940783/
    No Linux, em CPUs sem microcódigo atualizado, o AVX é totalmente desativado como mitigação para esse problema. Para mim, isso é bem severo e deve ser bastante perceptível. Agora fiquei com vontade de descobrir se consigo receber o microcódigo atualizado

    • A desativação do AVX só se aplica ao usar gather_data_sampling=force. O padrão é deixar o AVX como está e marcar o sistema como vulnerável
      Em https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin..., vemos:
      Ao especificar gather_data_sampling=force, usa-se a mitigação por microcódigo quando possível e, em sistemas afetados cujo microcódigo não foi atualizado para incluir essa mitigação, o AVX é desativado
      Para constar, trabalho com Linux na Intel. É bem possível que eu tenha escrito ou revisado a documentação e os changelogs que estão confundindo as pessoas
    • [ 0.000000] microcode: updated early: 0x27 -> 0x28, date = 2019-11-12
      Estou usando Haswell. Existe uma lista de quais CPUs recebem microcódigo atualizado? Que pena
    • Talvez não seja o padrão. Só pelo texto, não fica totalmente claro

  • Também vale notar que o GCP corrigiu esse problema: https://cloud.google.com/support/bulletins#gcp-2023-024

    • Equipes vizinhas de SRE do Google Cloud (GCE) em Londres distribuíram o patch a tempo e receberam hoje os donuts que mereciam
    • Comunicado correspondente da AWS: https://aws.amazon.com/security/security-bulletins/AWS-2023-...
      Os dados e instâncias dos clientes da AWS não são afetados por esse problema, e não há nenhuma ação que os clientes precisem tomar
      A AWS projetou e implementou infraestrutura com proteções contra essa classe de problema. Instâncias do Amazon EC2, incluindo Lambda, Fargate e outros serviços de computação e contêineres gerenciados pela AWS, protegem os dados dos clientes contra GDS por meio de microcódigo e mitigações baseadas em software

  • O impacto no desempenho é enorme. Alega-se até 50%, e dizem que 70% dos processadores Intel recentes são afetados

    • “Nos testes internos de desempenho da Red Hat, os piores microbenchmarks apresentaram grande desaceleração. Mas aplicações mais realistas que usam vector gather tiveram apenas desacelerações na casa de poucos pontos percentuais.”
      https://access.redhat.com/solutions/7027704
      O impacto no desempenho fica limitado a aplicações que usam as instruções gather fornecidas pelas Intel Advanced Vector Extensions (AVX2 e AVX-512) e a instrução CLWB. O impacto real no desempenho depende de quanto a aplicação usa essas instruções
      Se, após uma análise de risco rigorosa, o usuário decidir desativar a mitigação — por exemplo, se o sistema não for multitenant e não executar código não confiável —, é possível desativá-la
      Depois de aplicar as atualizações de microcódigo e do kernel, adicione gather_data_samping=off à linha de comando do kernel para desligar a mitigação. Ou use mitigations=off para desligar todas as mitigações de execução especulativa da CPU, incluindo GDS
    • Esse overhead de 50% é para a instrução “Gather”? Se for, quando 10% das instruções do workload forem gather, o overhead total será de 5%
    • A formulação é “alguns workloads podem sofrer até 50% de overhead”. Pelo fato de dizer alguns workloads, o impacto no desempenho parece ser raro
    • O contexto essencial que falta é: “depende de haver Gather no caminho crítico de execução do programa”
    • É parecido com ver “até 70% de desconto” e achar que é uma liquidação enorme. Às vezes há só uns dois itens na loja inteira com 70% de desconto
      Sempre desconfio de afirmações com “até”

  • O NES vinha com um chipset que tinha um 6502 inteiro embutido, e pelo preço de uma pizza dá para comprar um chip ARM da Rockchip com núcleos mistos no die. Talvez os fabricantes de chips não precisem resolver todos os casos extremos para sempre, e possam devolver a nós, que consumimos chips, essas mitigações de ataques por canal lateral
    Em vez de fazer do SMT uma escolha de tudo ligado ou tudo desligado, que tal mandar código não confiável para os “núcleos ruins” e fazer o cliente “provar” que ele pode ser promovido para núcleos com SMT?
    Ninguém quer estragar um chip que roda trabalhos de folha de pagamento ultracríticos, nos quais não dá para colocar outra coisa na placa. Mas tudo bem ser obrigado a marcar o que pode rodar com segurança em SMT e, caso contrário, ficar preso a um núcleo mais seguro
    Um estagiário que não faz a menor ideia do que é isso pode pesquisar, aprender qual é de fato esse vetor de ataque e talvez elaborar um plano de defesa
    Estou viajando?

    • Vejo isso como um problema de mercado
      Núcleos de desempenho × núcleos de eficiência são viáveis
      Mas ninguém vai querer ser a pessoa que propõe núcleos confiáveis × núcleos não confiáveis “ruins”. Por mais vantagens que tenha, isso seria soterrado pelo discurso de que “está fomentando insegurança”. A vida é assim