Duas falhas graves de segurança no kernel do Linux foram (finalmente) corrigidas esta semana. A primeira (Januscape) permitia que um invasor que alugasse uma máquina virtual em serviços de nuvem escapasse desse ambiente limitado e assumisse o controle total do servidor físico no qual ela estivesse hospedada.
Por sua vez, e igualmente preocupante, a segunda (GhostLock) possibilitava que um usuário comum do sistema ganhasse privilégios máximos, se tornando administrador da máquina. Ambas estavam escondidas no código há mais de 15 anos.
| Característica | Januscape | GhostLock |
|---|---|---|
| CVE | CVE-2026-53359 | CVE-2026-43499 |
| Tipo de falha | Use-after-free (corrupção de memória) | Use-after-free (corrupção de memória) |
| O que afeta | KVM, o sistema que cria e gerencia máquinas virtuais no Linux | Código que organiza a fila de tarefas do processador (herança de prioridade futex) |
| Tempo escondida | 16 anos | 15 anos |
| O que um invasor consegue fazer | Controlar o servidor físico a partir de uma máquina virtual alugada (RCE) ou derrubar todas as máquinas virtuais do mesmo servidor (DoS) | Virar administrador (root) do sistema partindo de uma conta comum |
| O que o invasor precisa ter | Privilégios de root dentro da máquina virtual | Uma conta com direitos limitados no sistema |
| Processadores afetados | AMD e Intel | — |
| Quem descobriu | Pesquisador Hyunwoo Kim | Equipe da Nebula Security, usando o scanner com inteligência artificial Vega |
| Valor pago pelo Google (pelo programa kernelCTF Bug-Bounty) | US$ 250 mil | US$ 92.337 |
| Nota de gravidade | — | 7.8 de 10 |
O risco para serviços de nuvem
O Januscape funciona dentro do KVM, que é o programa responsável por criar máquinas virtuais dentro do Linux. O problema está na parte que traduz endereços de memória entre a máquina virtual e o servidor físico que a hospeda, um processo chamado emulação de MMU sombra.
O pesquisador Hyunwoo Kim explicou que o ataque parte exclusivamente de dentro da máquina virtual. Um invasor que alugou uma única instância em um serviço de nuvem pública pode causar o travamento do servidor físico, derrubando junto todas as outras máquinas virtuais de outros clientes que estão na mesma máquina.
A outra possibilidade é executar comandos como administrador do servidor físico, assumindo o controle da máquina e de todas as máquinas virtuais hospedadas nela.
Kim publicou um código de demonstração que, rodado dentro da máquina virtual, faz o servidor físico travar.
Ele afirmou que também tem um código que escapa completamente da máquina virtual e dá controle total sobre o servidor, mas que só vai publicá-lo em um futuro muito distante.
A falha não está no QEMU, outro programa que também trabalha com memória na virtualização. Isso significa que o ataque funciona mesmo em nuvens que montam seu próprio ambiente de virtualização, sem usar as configurações padrão.
Leia mais
- Driver aberto da NVIDIA dá passo histórico e ganha suporte experimental ao DLSS no Linux
- Linux finalmente corrige bug que limitava placas de captura 4K a 30 FPS
- Valve trabalha diretamente com a NVIDIA no suporte ao SteamOS
Como o GhostLock transformava um usuário comum em administrador
Matt Lucas, pesquisador e fundador da RedEye Security, detalhou que o GhostLock está em uma parte do kernel que gerencia a fila de tarefas do processador.
Esse sistema existe para evitar que uma tarefa urgente fique parada, esperando atrás de uma tarefa sem importância.
O problema aparece em um momento muito específico: quando uma operação chega a um beco sem saída e precisa retroceder.
Nessa hora, a limpeza que o sistema faz acontece no momento errado e apaga o registro da tarefa incorreta. O kernel fica segurando uma referência a um pedaço de memória que já foi apagado e reaproveitado para outra coisa. Confiar nessa referência velha é o erro completo, explicou Lucas.
A equipe da Nebula Security usou esse erro como ponto de partida e montou uma sequência de passos para enganar o kernel e fazê-lo executar comandos como se fosse o administrador do sistema.
O código no qual o problema está foi escrito em 2011 e, por ser muito usado e raramente revisado, a falha passou despercebida por todos esses anos.
Para finalizar, ressaltamos que ambas as falhas já receberam correções oficiais no kernel do Linux. Quem usa sistema operacional deve verificar com a distribuição responsável se a atualização correspondente já está disponível para a versão instalada.
E aí? O que achou sobre o polêmico assunto? Compartilhe as suas opiniões e continue acompanhando o Adrenaline!
Fonte: arstechnica
