Retbleed é um novo ataque ao mecanismo de execução especulativa de CPUs Intel e AMD

Um grupo de pesquisadores da ETH Zurique identificou um novo ataque ao mecanismo de execução especulativa de transições indiretas na CPU, que permite extrair informações da memória do kernel ou organizar um ataque ao sistema host a partir de máquinas virtuais. As vulnerabilidades têm o codinome Retbleed (CVE-2022-29900, CVE-2022-29901) e são de natureza próxima aos ataques Spectre-v2. A diferença se resume à organização da execução especulativa de código arbitrário ao processar a instrução “ret” (return), que busca o endereço para pular da pilha, ao invés de um salto indireto usando a instrução “jmp”, carregando o endereço de memória ou um registro da CPU.

Um invasor pode criar condições para uma previsão de transição incorreta e organizar uma transição direcionada e especulativa para um bloco de código que não é fornecido pela lógica de execução do programa. Em última análise, o processador determinará que a previsão do desvio não foi justificada e reverterá a operação ao seu estado original, mas os dados processados ​​​​durante a execução especulativa terminarão no cache e nos buffers da microarquitetura. Se um bloco executado erroneamente acessar a memória, sua execução especulativa fará com que os dados lidos da memória sejam depositados no cache compartilhado.

Para determinar os dados restantes no cache após operações especulativas, um invasor pode usar técnicas de canal lateral para determinar dados residuais, como analisar alterações nos tempos de acesso a dados armazenados e não armazenados em cache. Para extrair propositalmente informações de áreas em outro nível de privilégio (por exemplo, da memória do kernel), são usados ​​“gadgets” - sequências de comandos presentes no kernel que são adequadas para leitura especulativa de dados da memória, dependendo de condições externas que podem ser influenciadas por o atacante.

Para se proteger contra ataques clássicos da classe Spectre que usam instruções de salto condicionais e indiretos, a maioria dos sistemas operacionais usa a técnica “retpoline”, que se baseia na substituição de operações de salto indireto pela instrução “ret”, para a qual os processadores usam uma unidade de predição de estado de pilha separada. .não usar um bloco de previsão de ramificação. Quando a retpoline foi introduzida em 2018, acreditava-se que as manipulações de endereço do tipo Spectre não eram práticas para ramificação especulativa usando a instrução “ret”.

Os pesquisadores que desenvolveram o método de ataque Retbleed demonstraram a possibilidade de criar condições microarquitetônicas para iniciar uma transição especulativa usando a instrução “ret” e publicaram ferramentas prontas para identificar sequências de instruções (gadgets) adequadas para explorar a vulnerabilidade no kernel Linux, em que tais condições se manifestam.

Durante a pesquisa, foi preparada uma exploração funcional que permite, em sistemas com CPUs Intel, extrair dados arbitrários da memória do kernel de um processo sem privilégios no espaço do usuário a uma velocidade de 219 bytes por segundo e 98% de precisão. Nos processadores AMD, a eficiência da exploração é muito maior – a taxa de vazamento é de 3.9 KB por segundo. Como exemplo prático, mostramos como utilizar o exploit proposto para determinar o conteúdo do arquivo /etc/shadow. Em sistemas com CPUs Intel, o ataque para determinar o hash da senha do usuário root foi realizado em 28 minutos, e em sistemas com CPUs AMD - em 6 minutos.

O ataque foi confirmado para as gerações 6-8 de processadores Intel lançados antes do terceiro trimestre de 3 (incluindo Skylake) e processadores AMD baseados nas microarquiteturas Zen 2019, Zen 1+ e Zen 1 que foram lançados antes do segundo trimestre de 2. Em modelos de processadores mais recentes, como AMD Zen2021 e Intel Alder Lake, bem como em processadores ARM, o problema é bloqueado pelos mecanismos de proteção existentes. Por exemplo, usar instruções IBRS (especulação restrita de ramificação indireta) ajuda a proteger contra ataques.

Um conjunto de mudanças foi preparado para o kernel Linux e o hipervisor Xen, que irá bloquear o problema em software em CPUs mais antigas. O patch proposto para o kernel Linux altera 68 arquivos, adiciona 1783 linhas e exclui 387 linhas. Infelizmente, a proteção leva a custos indiretos significativos - nos textos realizados sobre processadores AMD e Intel, a queda de desempenho é estimada de 14% a 39%. É mais preferível usar proteção baseada nas instruções IBRS, disponíveis nas novas gerações de CPUs Intel e suportadas a partir do kernel Linux 4.19.

Nos processadores Intel, a substituição de endereço para um salto indireto especulativo é realizada graças a um recurso que aparece quando ocorre um overflow através do limite inferior (underflow) no Return Stack Buffer. Quando tais condições ocorrem, a instrução “ret” começa a aplicar uma lógica de seleção de endereço semelhante àquela usada para saltos indiretos normais. Mais de mil locais foram encontrados no kernel do Linux que criam condições para iniciar tal refluxo e são acessíveis por meio de chamadas de sistema.

Nos processadores AMD, a execução especulativa da instrução “ret” é realizada sem referência a um buffer específico da pilha (Return Address Stack) e a unidade de previsão de desvio considera a instrução “ret” não como um retorno de controle, mas como um desvio indireto e, consequentemente, usa os dados para prever transições indiretas. Sob estas condições, praticamente qualquer operação “ret” acessível através de uma chamada de sistema pode ser explorada.

Além disso, outro problema também foi identificado em CPUs AMD (CVE-2022-23825, Branch Type Confusion) relacionado à implementação de ramificações fictícias - condições para predição de ramificação podem ocorrer mesmo sem as instruções de ramificação necessárias, o que permite influenciar o buffer de predição de ramificação sem a instrução "ret". Esse recurso complica significativamente a implementação da proteção e requer uma limpeza mais ativa do buffer de previsão de ramificação. Espera-se que adicionar proteção total ao kernel aumente a sobrecarga em 209%.

Fonte: opennet.ru

Adicionar um comentário