Um bug no Linux 6.2 permitiu ignorar a proteção contra ataques Spectre v2

Recentemente, foram divulgadas informações sobre um vulnerabilidade identificada no kernel Linux 6.2 (já listado em CVE-2023-1998) e que se destaca por ser desative a proteção contra ataques do Spectre v2 que permitem o acesso à memória por outros processos em execução em diferentes threads SMT ou Hyper Threading, mas no mesmo núcleo do processador físico.

A vulnerabilidade é notável, entre outras coisas, porque pode ser usado para organizar o vazamento de dados entre máquinas virtuais em sistemas de nuvem. 

Para aqueles que não conhecem o Spectre, devem saber que este é uma das duas vulnerabilidades originais da CPU de execução transitória (o outro é Meltdown), que envolve ataques de canal lateral de temporização de microarquitetura. Isso afeta microprocessadores modernos que executam previsões de salto e outras formas de especulação.

Na maioria dos processadores, a execução especulativa resultante de uma previsão de ramificação errada pode deixar efeitos colaterais observáveis ​​que podem revelar dados privados. Por exemplo, se o padrão de acessos à memória feitos por tal execução especulativa depende dos dados privados, o estado resultante do cache de dados constitui um canal lateral através do qual um invasor pode extrair informações sobre os dados privados usando um ataque de tempo.

Desde a divulgação de Spectre e Meltdown em janeiro de 2018, várias variantes e novos tipos de vulnerabilidade relacionados a eles surgiram.

O kernel do Linux permite que processos userland habilitem mitigações chamando prctl com PR_SET_SPECULATION_CTRL, que desabilita a função spec, bem como usando seccomp. Descobrimos que em máquinas virtuais de pelo menos um dos principais provedores de nuvem, o kernel ainda deixava o processo da vítima aberto a ataques em alguns casos, mesmo depois de habilitar a mitigação de Specter-BTI com prctl. 

Em relação à vulnerabilidade, é mencionado que no espaço do usuário, para proteger contra ataques de Espectro, os processos podem desabilitar seletivamente a execução instruções especulativas com prctl PR_SET_SPECULATION_CTRL ou use filtragem de chamada de sistema baseada em seccomp.

Segundo os pesquisadores que identificaram o problema, otimização incorreta no kernel 6.2 deixou as máquinas virtuais de pelo menos um grande provedor de nuvem sem proteção adequada apesar da inclusão do modo de bloqueio de ataque Specter-BTI via prctl. A vulnerabilidade também se manifesta em servidores normais com kernel 6.2, que são iniciados com a configuração "spectre_v2=ibrs".

A essência da vulnerabilidade é que, ao escolher os modos de proteção IBRS ou eIBRS, as otimizações realizadas desabilitaram o uso do mecanismo STIBP (Single Thread Indirect Branch Predictors), necessário para bloquear vazamentos quando se utiliza a tecnologia Simultaneous Multi-Threading (SMT ou Hyper-Threading). )

Por sua vez, apenas o modo eIBRS oferece proteção contra vazamentos entre threads, não o modo IBRS, pois com ele o bit IBRS, que fornece proteção contra vazamentos entre núcleos lógicos, é zerado por questões de desempenho quando o controle retorna ao usuário do espaço, o que torna threads do espaço do usuário desprotegidos contra ataques da classe Spectre v2.

O teste consiste em dois processos. O invasor envenena constantemente uma chamada indireta para redirecioná-la especulativamente para um endereço de destino. O processo da vítima mede a taxa de predição errada e tenta mitigar o ataque chamando PRCTL ou gravando diretamente no MSR usando um módulo do kernel que expõe as operações de leitura e gravação do MSR no espaço do usuário.

O problema afeta apenas o kernel do Linux 6.2 e é devido à implementação incorreta de otimizações projetadas para reduzir sobrecarga significativa ao aplicar proteção contra Spectre v2. vulnerabilidade Foi corrigido no ramo experimental do kernel Linux 6.3.

Enfim sim Você está interessado em aprender mais sobre isso? você pode verificar os detalhes no link a seguir