Kernel Linux permite ataque do Spectre ao 'principal provedor de nuvem'

Kernel Linux permite ataque do Spectre ao 'principal provedor de nuvem'
Kernel Linux permite ataque do Spectre ao ‘principal provedor de nuvem’

A vulnerabilidade do Spectre que assombra os fabricantes de hardware e software desde 2018 continua a desafiar os esforços para acabar de uma vez por todas com o problema. Assim, o Kernel Linux permite ataque do Spectre ao ‘principal provedor de nuvem’

Na semana passada, Eduard (sirdarckcat) Vela Nava, da equipe de resposta de segurança de produtos do Google, divulgou uma falha relacionada ao Spectrum na versão 6.2 do kernel Linux.

O bug, designado de gravidade média, foi inicialmente relatado aos provedores de serviços em nuvem – aqueles com maior probabilidade de serem afetados – em 31 de dezembro de 2022 e foi corrigido no Linux em 27 de fevereiro de 2023.

“O kernel falhou em proteger aplicativos que tentavam proteger contra o Spectre v2, deixando-os abertos a ataques de outros processos em execução no mesmo núcleo físico em outro hyperthread”, explica a divulgação da vulnerabilidade. A consequência desse ataque é a exposição potencial de informações (por exemplo, chaves privadas vazadas) por meio desse problema pernicoso.

O apelido Spectre [PDF] descreve um conjunto de vulnerabilidades que abusam da execução especulativa, uma otimização de desempenho do processador na qual as instruções potenciais são executadas com antecedência para economizar tempo.

É o timing, no entanto, que anima Spectre. O Spectre v2 – a variante implicada nesta vulnerabilidade em particular – baseia-se em canais laterais de temporização para medir as taxas de previsão incorreta da previsão de ramificação indireta, a fim de inferir o conteúdo da memória protegida. Isso está longe de ser o ideal em um ambiente de nuvem com hardware compartilhado.

Kernel Linux permite ataque do Spectre ao ‘principal provedor de nuvem’

Kernel Linux permite ataque do Spectre ao 'principal provedor de nuvem'

Pouco depois que o The Register informou pela primeira vez sobre a disputa para corrigir os bugs Meltdown e Spectre, a Intel publicou detalhes sobre a Especulação Restrita de Ramificação Indireta (IBRS), um mecanismo para restringir a especulação de ramificações indiretas, que dizem aos processadores para começar a executar instruções em um novo local.

O IBRS oferece uma defesa contra o Spectre v2, que a Intel chama de Branch Target Injection. A injeção de destino de ramificação é uma técnica para treinar preditores de ramificação para executar especulativamente certas instruções a fim de inferir dados no cache do processador usando um canal lateral de temporização.

O IBRS vem em dois sabores: básico (legado) e aprimorado. E é o sabor básico que se mostrou desagradável do ponto de vista da segurança.

Os caçadores de bugs que identificaram o problema descobriram que os processos de espaço de usuário do Linux para se defender contra o Spectre v2 não funcionavam em VMs de “pelo menos um grande provedor de nuvem”.

Como a divulgação descreve, sob o IBRS básico, o kernel 6.2 tinha lógica que optava por não participar do STIBP (Single Thread Indirect Branch Predictors), uma defesa contra o compartilhamento de previsão de ramificação entre processadores lógicos em um núcleo.

“O bit IBRS protege implicitamente contra a injeção de alvo de ramificação cruzada”, explica o relatório de bugs. “No entanto, com o IBRS legado, o bit IBRS foi limpo ao retornar ao espaço do usuário, devido a razões de desempenho, o que desabilitou o STIBP implícito e deixou os threads do espaço do usuário vulneráveis à injeção de alvo de ramificação cross-thread contra a qual o STIBP protege.”

O Register entende que o problema surgiu de um mal-entendido do IBRS aprimorado, que não precisa do STIBP para se proteger contra outro thread (ataques simultâneos de multithreading).

A correção removeu o IBRS básico da verificação, a fim de manter o STIBP ativado por padrão.spectre_v2_in_ibrs_mode()

A falha fantasmagórica foi identificada por Rodrigo Rubira Branco (BSDaemon), quando estava no Google, e José Luiz. KP Singh, parte da equipe do kernel do Google, que trabalhou na correção e coordenou com os mantenedores do Linux para resolver o problema.

Acesse a versão completa
Sair da versão mobile