ÁPICO/ÉPICO! Os chips da Intel vazam segredos que nem o kernel deveria ver…

Aqui está o BWAIN desta semana, nosso termo jocoso para um Bug com um nome impressionante.

O BWAIN é um prêmio que entregamos quando uma nova falha de segurança cibernética não apenas se torna interessante e importante, mas também aparece com seu próprio logotipo, nome de domínio e site.

Este é dublado Vazamento ÆPIC, um trocadilho com as palavras APIC e ÉPICO.

O primeiro é curto para Controlador de interrupção programável avançado, e este último é simplesmente a palavra “épico”, como em gigante, maciço, extremo, Mega, humongous.

A letra Æ não é usada em inglês escrito desde os tempos saxões. Seu nome é asc, pronunciado cinza (como na árvore), e representa muito bem o som do A na palavra moderna ASH. Mas assumimos que você deveria pronunciar a palavra ÆPIC aqui como “APIC-slash-EPIC”, ou como “ah!-eh?-PIC”.

Do que se trata?

Tudo isso levanta cinco questões fascinantes:

• O que é um APIC, e por que eu preciso disso?
• Como você pode ter dados que mesmo o núcleo não pode espiar?
• O que causa esse fracasso épico em APIC?
• Faz o Vazamento ÆPIC me afeta?
• O que fazer sobre isso?

O que é um APIC?

Voltemos a 1981, quando o IBM PC apareceu pela primeira vez.

O PC incluía um chip chamado Controlador de interrupção programável Intel 8259A, ou PIC. (Modelos posteriores, a partir do PC AT, tinham dois PICs, encadeados, para suportar mais eventos de interrupção.)

O objetivo do PIC era literalmente interromper o programa em execução no processador central do PC (CPU) sempre que algo crítico de tempo ocorresse e precisasse de atenção imediata.

Essas interrupções de hardware incluíam eventos como: o teclado sendo pressionado; a porta serial recebendo um caractere; e um timer de hardware repetitivo passando.

Sem um sistema de interrupção de hardware desse tipo, o sistema operacional precisaria estar repleto de chamadas de função para verificar as teclas digitadas regularmente, o que seria um desperdício de energia da CPU quando ninguém estivesse digitando, mas não responderia suficiente quando o fizeram.

Como você pode imaginar, o PIC foi logo seguido por um chip atualizado chamado APIC, um avançado tipo de PIC embutido na própria CPU.

Atualmente, os APICs fornecem muito mais do que apenas feedback do teclado, porta serial e timer do sistema.

Os eventos APIC são acionados por (e fornecem dados em tempo real sobre) eventos como superaquecimento e permitem a interação de hardware entre os diferentes núcleos em processadores multicore contemporâneos.

E os chips Intel de hoje, se pudermos simplificar bastante, geralmente podem ser configurados para funcionar de duas maneiras diferentes, conhecidas como Modo xAPIC e Modo x2APIC.

Aqui, xAPIC é a maneira “legada” de extrair dados do controlador de interrupção, e x2APIC é a forma mais moderna.

Simplificando ainda mais, xAPIC conta com o que é chamado MMIO, abreviatura de entrada/saída mapeada em memória, para leitura de dados do APIC quando este registra um evento de interesse.

No modo MMIO, você pode descobrir o que acionou um evento APIC lendo de uma região específica da memória (RAM), que espelha os registros de entrada/saída do próprio chip APIC.

Esses dados xAPIC são mapeados em um bloco de memória de 4096 bytes em algum lugar na RAM física do computador.

Isso simplifica o acesso aos dados, mas requer uma interação irritante, complexa (e, como veremos, potencialmente perigosa) entre o chip APIC e a memória do sistema.

Em contraste, x2APIC requer que você leia os dados APIC diretamente do próprio chip, usando o que é conhecido como Registros Específicos do Modelo (MSR).

De acordo com a Intel, evitar a parte MMIO do processo “fornece uma capacidade de endereçamento do processador significativamente maior e alguns aprimoramentos na entrega de interrupção”.

Notavelmente, extrair os dados APIC diretamente dos registros no chip significa que a quantidade total de dados suportados e o número máximo de núcleos de CPU que podem ser gerenciados ao mesmo tempo não se limita aos 4096 bytes disponíveis no modo MMIO.

Como você pode ter dados que nem mesmo o kernel pode espiar?

Você provavelmente já adivinhou que os dados que acabam na área de memória MMIO quando você está usando o modo xAPIC nem sempre são gerenciados com tanto cuidado quanto deveriam…

…e, portanto, algum tipo de “vazamento de dados” nessa área MMIO é o coração desse problema.

Mas dado que você já precisa de poderes de nível sysadmin para ler os dados MMIO em primeiro lugar e, portanto, você quase certamente poderia obter todos e quaisquer dados na memória de qualquer maneira ...

… por que ter os dados de outras pessoas aparecendo por engano na área de dados APIC MMIO representaria um épico vazar?

Isso pode tornar alguns tipos de ataque de roubo de dados ou de raspagem de RAM um pouco mais fáceis na prática, mas certamente não lhe daria mais capacidade de espionagem de memória que você já tinha em teoria?

Infelizmente, essa suposição não é verdadeira se algum software no sistema estiver usando o SGX da Intel, abreviação de Extensões de proteção de software.

---

SAIBA MAIS SOBRE O SGX

---

O SGX é suportado por muitas CPUs recentes da Intel e fornece uma maneira para o kernel do sistema operacional “selar” um pedaço de código e dados em um bloco físico de RAM para formar o que é conhecido como enclave.

Isso faz com que ele se comporte, pelo menos temporariamente, como os chips de segurança especiais em telefones celulares que são usados ​​para armazenar segredos, como chaves de descriptografia.

Uma vez que o “bloqueio” SGX do enclave é definido, apenas o código do programa executado dentro da área de memória lacrada pode ler e gravar o conteúdo dessa RAM.

Como resultado, os detalhes internos de quaisquer cálculos que ocorrem após a ativação do enclave são invisíveis para qualquer outro código, thread, processo ou usuário no sistema.

Incluindo o próprio kernel.

Há uma maneira de chamar o código que foi selado no enclave e uma maneira de retornar a saída dos cálculos que ele pode realizar, mas não há como recuperar, espionar ou depurar o código e seus dados associados enquanto ele é executado.

O enclave se transforma efetivamente em uma caixa preta na qual você pode alimentar entradas, como dados a serem assinados com uma chave privada, e extrair saídas, como a assinatura digital gerada, mas da qual você não pode extrair as chaves criptográficas usado no processo de assinatura.

Como você pode imaginar, se os dados que deveriam ser selados dentro de um enclave SGX forem duplicados acidentalmente na RAM MMIO que é usada para “espelhar” os dados APIC quando você está usando o modo xAPIC “mapeado em memória”…

…isso violaria a segurança do SGX, que diz que nenhum dado deve emergir de um enclave SGX depois de ter sido criado, a menos que seja deliberadamente exportado por código já em execução dentro do próprio enclave.

O que causa essa falha épica no APIC?

Os pesquisadores por trás do ÆPIC Vazamento de papel descobriu que, organizando a leitura de dados APIC por meio de uma sequência astuta e incomum de acessos à memória…

… eles poderiam enganar o processador para preencher o espaço APIC MMIO não apenas com dados recém-recebidos do próprio APIC, mas também com dados que acabaram de ser usados ​​pela CPU recentemente para algum outro propósito.

Esse comportamento é um efeito colateral do fato de que, embora a página de memória APIC MMIO tenha 4096 bytes de tamanho, o chip APIC no modo xAPIC na verdade não produz 4096 bytes de dados e a CPU nem sempre neutraliza corretamente as partes não utilizadas da região MMIO, preenchendo-a primeiro com zeros.

Em vez disso, os dados antigos deixados no cache da CPU foram gravados junto com os novos dados recebidos do próprio chip APIC.

Como os pesquisadores dizem, o bug se resume ao que é conhecido como leitura de memória não inicializada, onde você acidentalmente reutiliza os dados restantes de outra pessoa na RAM porque nem eles nem você os liberaram de seus segredos anteriores primeiro.

O vazamento ÆPIC me afeta?

Para obter uma lista completa de chips afetados, consulte Consultoria da própria Intel.

Até onde sabemos, se você tiver um processador Intel de 10ª ou 11ª geração, provavelmente será afetado.

Mas se você tiver uma CPU de 12ª geração totalmente nova (a mais recente no momento da redação), parece que apenas os chips de classe de servidor são afetados.

Ironicamente, em chips de laptop de 12ª geração, a Intel desistiu do SGX, então esse bug não se aplica porque é impossível ter enclaves SGX “lacrados” que possam vazar.

É claro que, mesmo em um chip potencialmente vulnerável, se você não estiver confiando em nenhum software que use SGX, o bug também não se aplica.

E o bug, apelidado CVE-2022-21233, só pode ser explorado por um invasor que já tenha acesso local em nível de administrador (raiz) ao seu computador.

Usuários regulares não pode acessar o bloco de dados APIC MMIO e, portanto, não tem como espiar nada lá, muito menos dados secretos que possam ter vazado de um enclave SGX.

Também, máquinas virtuais convidadas (VMs) em execução sob o controle de um sistema operacional host em um hipervisor como HyperV, VMWare ou VirtualBox quase certamente não podem usar esse truque para saquear segredos de outros convidados ou do próprio host.

Isso ocorre porque as VMs convidadas geralmente não obtêm acesso ao circuito APIC real no processador host; em vez disso, cada convidado obtém seu próprio APIC simulado exclusivo para essa VM.

O que fazer?

Não entre em pânico.

Em um laptop ou computador de mesa, você pode não estar em risco algum, seja porque tem um computador mais antigo (ou, felizmente, um novo!) ou porque não está confiando no SGX de qualquer maneira.

E mesmo se você for um risco, qualquer pessoa que entrar em seu laptop como administrador/root provavelmente já tem poder suficiente para causar um mundo de problemas.

Se você tiver servidores vulneráveis ​​e estiver contando com o SGX como parte de sua segurança operacional, verifique o comunicado de segurança da Intel INTEL-SA-00657 para informações de proteção e mitigação.

De acordo com os pesquisadores que escreveram isso, “A Intel [lançou] atualizações de microcódigo e SGX Software Development Kit para corrigir o problema.”

A equipe do kernel Linux também parece estar trabalhando agora em um patch que permitirá que você configure seu sistema para que ele sempre use x2APIC (que, como você deve se lembrar anteriormente, não transmite dados APIC via memória compartilhada), e evitará graciosamente que o sistema seja forçado de volta ao modo xAPIC após a inicialização.

---