Um grupo de pesquisadores da Escola Politécnica Federal de Zurique identificou uma nova variante de ataque ao mecanismo de execução especulativa de saltos indiretos em CPUs, permitindo extrair informações da memória do núcleo ou organizar um ataque ao sistema host a partir de máquinas virtuais. As vulnerabilidades receberam o codinome Retbleed (CVE-2022-29900, CVE-2022-29901) e são semelhantes, em essência, aos ataques do Spectre-v2. A diferença reside na organização da execução especulativa de código arbitrário ao processar a instrução "ret" (return), que extrai o endereço de salto da pilha, em vez de um salto indireto utilizando a instrução "jmp" para carregar o endereço da memória ou do registrador da CPU.
O atacante pode criar condições para uma previsão incorreta de salto e organizar um salto especulativo direcionado para um bloco de código não previsto pela lógica de execução do programa. No final, o processador determinará que a previsão de bifurcação estava errada e reverterá a operação ao estado original, mas os dados processados durante a execução especulativa permanecerão em cache e em buffers microarquiteturais. Se o bloco executado erroneamente acessa a memória, sua execução especulativa resultará na permanência de dados no cache geral e em dados lidos da memória.
Para identificar os dados que permaneceram no cache após a execução especulativa de operações, o atacante pode usar métodos de determinação de dados residuais por meio de canais laterais, como a análise das alterações no tempo de acesso a dados em cache e não em cache. Para a extração direcionada de informações de áreas em outro nível de privilégio (como a memória do núcleo), são utilizados "gadgets" — sequências de comandos presentes no núcleo que são adequadas para a leitura especulativa de dados da memória, dependendo de condições externas que podem ser influenciadas pelo atacante.
Para proteger contra ataques clássicos da categoria Spectre, que utilizam instruções de desvio condicional e indireto, a maioria dos sistemas operacionais aplica a técnica 'retpoline', baseada na substituição de operações de desvio indireto pela instrução 'ret'. Para esta instrução, os processadores utilizam um bloco separado de previsão de estado de pilha, que não utiliza o bloco de previsão de desvios. Quando a retpoline foi implementada em 2018, acreditava-se que manipulações semelhantes a Spectre com endereços não eram aplicáveis na prática para desvios especulativos usando a instrução 'ret'.
Pesquisadores que desenvolveram o método de ataque Retbleed demonstraram a possibilidade de criar condições microarquitetônicas para iniciar um desvio especulativo usando a instrução 'ret' e publicaram um conjunto de ferramentas prontas para identificar sequências de instruções vulneráveis (gadgets) no kernel do Linux, onde essas condições se manifestam.
Durante a pesquisa, foi preparado um exploit funcional que permite que sistemas com CPU Intel extraiam dados arbitrários da memória do kernel a partir de um processo não privilegiado no espaço do usuário, com uma velocidade de 219 bytes por segundo e precisão de 98%. Em processadores AMD, a eficácia do exploit é muito maior — a velocidade de vazamento atinge 3.9 KB por segundo. Como exemplo prático, foi mostrado como, utilizando o exploit proposto, determinar o conteúdo do arquivo /etc/shadow. Em sistemas com CPU Intel, o ataque para determinar o hash da senha do usuário root foi realizado em 28 minutos, enquanto em sistemas com CPU AMD, foi concluído em 6 minutos.
A possibilidade de realizar o ataque foi confirmada para processadores Intel da 6ª à 8ª geração, que foram lançados até o terceiro trimestre de 2019 (incluindo Skylake), e processadores AMD baseados nas microarquiteturas Zen 1, Zen 1+ e Zen 2, que foram lançados até o segundo trimestre de 2021. Em modelos de processadores mais novos, como AMD Zen3 e Intel Alder Lake, assim como em processadores ARM, o problema é mitigado por mecanismos de proteção existentes. Por exemplo, a aplicação de instruções IBRS (Indirect Branch Restricted Speculation) ajuda a proteger contra o ataque.
Um núcleo Linux e o hipervisor Xen receberam um conjunto de alterações, destinado a CPUs mais antigas que bloqueiam o problema por meio de software. O patch proposto para o núcleo Linux altera 68 arquivos, adiciona 1783 linhas e remove 387 linhas. Infelizmente, essa proteção resulta em custos adicionais significativos - nos testes realizados em processadores AMD e Intel, a redução de desempenho é estimada entre 14% e 39%. A proteção baseada em instruções IBRS, disponível em novas gerações de processadores Intel e suportada a partir do núcleo Linux 4.19, é mais preferida.
Em processadores Intel, a substituição de endereço para a transição indireta especulativa ocorre devido a uma característica que se manifesta durante o estouro inferior (underflow) no buffer de previsão de conteúdo da pilha (Return Stack Buffer). Quando essas condições ocorrem, a lógica de seleção de endereço para a instrução 'ret' começa a aplicar uma lógica semelhante à utilizada em transições indiretas normais. No núcleo Linux, mais de mil locais foram encontrados que criam condições que iniciam esse tipo de estouro reverso, acessível por meio de chamadas de sistema.
Em processadores AMD, a execução especulativa da instrução 'ret' ocorre sem a vinculação ao buffer de endereços específico da pilha (Return Address Stack), e o bloco de previsão de transições trata a instrução 'ret' não como um retorno de controle, mas como uma transição indireta, utilizando assim dados para transições indiretas na previsão. Nessas condições, praticamente qualquer operação 'ret' acessível por meio de uma chamada de sistema pode ser utilizada para exploração.
Além disso, em CPUs AMD, foi identificada mais um problema (CVE-2022-23825, Branch Type Confusion) relacionado à execução de transições fictícias - as condições para a previsão de transições podem surgir mesmo sem as instruções de ramificação necessárias, o que permite influenciar o buffer de previsão de transições sem a instrução 'ret'. Essa característica complica significativamente a implementação da proteção e exige uma limpeza mais ativa do buffer de previsão de transições. Espera-se que a adição de proteção completa no núcleo leve a um aumento de custos de 209%.
Fonte: opennet.ru
