Um grupo de pesquisadores da Universidade Livre de Amsterdã identificou várias novas vulnerabilidades da classe Spectre-v2, publicadas sob o codinome Training Solo, que permitem contornar os mecanismos de isolamento de memória. No contexto de sistemas de virtualização, as vulnerabilidades possibilitam a determinação do conteúdo da memória do ambiente host a partir de sistemas convidados, e no contexto de servidores, permitem identificar o conteúdo da memória do núcleo ao executar um exploit no espaço do usuário. Exemplos de exploits para a realização de tais ataques foram publicados no GitHub. Os exploits apresentados permitem extrair dados arbitrários da memória do núcleo a uma taxa de 17 KB/s, e da memória do hipervisor a 8,5 KB/s.
Nos ataques da classe Spectre-v2, para organizar a vazamento de dados, utiliza-se a substituição de valores no buffer de endereços de ramificação (Branch Target Buffer) ou no buffer de histórico de ramificações (Branch History Buffer), que são usados para prever a próxima operação de ramificação. Por meio de manipulações do histórico de ramificação, são criadas condições para previsões incorretas de ramificações durante a execução especulativa de instruções. A tarefa do atacante é garantir que, durante a operação especulativa de ramificação, o endereço para a ramificação seja retirado da área de memória desejada. Após a execução da ramificação especulativa, o endereço de ramificação lido da memória permanece no cache do processador (os dados necessários para o atacante são lidos da memória sob a forma do endereço). Para extrair informações do cache, pode ser utilizado um dos métodos de determinação do conteúdo do cache, com base na análise da variação do tempo de acesso a dados armazenados e não armazenados.
Os métodos de ataque Training Solo visam contornar os mecanismos de isolamento de áreas de execução (domain isolation), como IBPB, eIBRS e BHI_NO, utilizados para bloquear ataques da classe Spectre-v2. Por exemplo, a instrução IBPB (Indirect Branch Prediction Barriers) garante a redefinição do estado do bloco de previsões de ramificação a cada troca de contexto — ao transferir o controle entre o espaço do usuário e o núcleo ou entre um sistema convidado e o ambiente host. A redefinição do estado bloqueia a possibilidade de uso de código próprio para influenciar o comportamento do bloco de previsões de ramificações indiretas.
As diferenças dos métodos Training Solo residem no fato de que, para influenciar o bloco de previsão de transições, não se propõe a execução de código controlado pelo atacante, mas sim a utilização do código que já existe na área privilegiada de execução (núcleo ou hipervisor), de onde o atacante consegue obter vazamentos. No restante, os métodos lembram o ataque clássico Spectre-v2. Além disso, os pesquisadores identificaram dois problemas de hardware (CVE-2024-28956 e CVE-2025-24495) que permitem contornar completamente a separação das áreas de execução e realizar vazamentos de processos de outros usuários, de outros sistemas convidados ou do ambiente host.
Três tipos de ataques Training Solo foram propostos:
- Distorção da lógica de previsão de transições por meio da chamada de sequências de comandos (gadgets) já existentes no núcleo, que influenciam o conteúdo do buffer com o histórico de transições. Como tais gadgets, sugere-se utilizar o mecanismo de limitação de acesso a chamadas de sistema SECCOMP, que permite, por meio da substituição de seus filtros BPF, induzir uma transição indireta falsa no modo especulativo (os filtros em SECCOMP são definidos utilizando cBPF clássico, que está habilitado por padrão, ao contrário do eBPF). Durante os testes em CPUs Intel Tiger Lake e Lion Cove, a velocidade de vazamento usando esse método foi de 1,7 KB/s.
- Uso de colisões de IP (Instruction Pointer) no bloco de previsão de transições. O atacante pode criar condições nas quais o endereço para uma transição especulativa será escolhido apenas com base no endereço de transição já existente no buffer, sem levar em conta o histórico de transições. A ideia é que uma operação de transição indireta pode influenciar outra, se ocorrer uma colisão ao armazenar os hashes de seus endereços no BTB (Branch Target Buffer).
- Uso da influência de transições diretas na previsão de transições indiretas. Esse comportamento é causado por duas vulnerabilidades de hardware: CVE-2024-28956 - ITS (Indirect Target Selection) e CVE-2025-24495 - um problema com os núcleos Lion Cove da Intel. A velocidade de vazamento de dados da memória ao usar esse método foi de 17 KB/s. No exploit demonstrado para determinar o hash da senha do usuário root, armazenada na memória após a execução do comando 'passwd -s', foram gastos 60 segundos.
Todos os CPUs Intel com suporte ao mecanismo eIBRS, incluindo os CPUs Intel Coffee Lake e Lion Cove, estão sujeitos a ataques que distorcem o buffer do histórico de transições. Para bloquear a vulnerabilidade, a Intel lançou uma atualização de microcódigo implementando uma nova instrução IBHF (Indirect Branch History Fence), que deve ser especificada após o código que afeta o buffer do histórico de transições. Para CPUs Intel mais antigas, foi sugerido o uso de um método de software para limpar o histórico de transições. Uma alteração foi incorporada ao núcleo Linux, adicionando proteção programática e de hardware contra ataques realizados usando cBPF.A AMD declarou que o método de ataque não se aplica a seus CPUs. A ARM informou que o problema afeta apenas processadores ARM mais antigos, vulneráveis a ataques Spectre-v2 e que não suportam as extensões FEAT_CSV2_3 e FEAT_CLRBHB.
A vulnerabilidade Indirect Target Selection (ITS, CVE-2024-28956) afeta CPUs Intel Core das 9ª a 11ª gerações (Cascade Lake, Cooper Lake, Whiskey Lake V, Coffee Lake R, Comet Lake, Ice Lake, Tiger Lake e Rocket Lake) e Intel Xeon de 2ª e 3ª gerações. A vulnerabilidade CVE-2025-24495 se manifesta em CPUs baseadas nas microarquiteturas Lunar Lake e Arrow Lake. Os problemas foram corrigidos na atualização de microcódigo de ontem. Uma alteração foi incorporada ao núcleo Linux, bloqueando o problema ao transferir os saltos indiretos para o topo da linha de cache.
Fonte: opennet.ru
