Recentemente, surgiram notícias de que pesquisadores da equipe do Google Project Zero desenvolveram um método para explorar vulnerabilidades no kernel do Linux causadas pelo desreferenciamento do ponteiro NULL.
Até agora, problemas no kernel relacionados a desreferenciação de ponteiro NULL não receberam a devida atenção, pois era considerado irreal transformar tais problemas em ataques que levariam a escalonamento de privilégios ou execução de código próprio (proibido mapear processos não privilegiados na região inferior do espaço de endereçamento).
Via de regra, tais erros levam à geração de avisos de oops pelo kernel, após os quais as tarefas problemáticas são concluídas e o estado é restaurado sem a necessidade de parar o sistema.
O novo método de ataque depende da manipulação de estados “oops”, o que pode resultar em um aumento no valor do refcount, que por sua vez pode causar o estouro do contador e liberar memória associada ao refcount.
Nesse caso, a exploração é reduzida a manipulações típicas de ataques use-after-free (surge uma situação em que a contagem de referência do objeto se torna zero, a memória é liberada, mas na verdade existem links de trabalho apontando para a memória liberada).
Atualmente, quando o kernel do Linux aciona um cancelamento de referência nulo de dentro de um contexto de processo, ele gera um oops , que é diferente de um kernel panic. Um pânico ocorre quando o kernel determina que não há maneira segura de continuar a execução e, portanto, toda a execução deve ser interrompida. No entanto, o kernel não interrompe todas as execuções durante um oops; em vez disso, o kernel tenta se recuperar da melhor maneira possível e continua a execução.
Project Zero tem um método para explorar vulnerabilidades no Linux
Desreferenciar um ponteiro NULL é usado aqui como uma forma de gerar o estado “oops” de maneira controlada. O problema é que são necessárias cerca de 232 chamadas de status “oops” para atingir um estouro de refcount de 32 bits.
Do ponto de vista prático, leva cerca de 8 dias de geração contínua de estados “oops” para realizar um ataque usando o exploit proposto. Se bem-sucedida, a exploração permite que você obtenha a execução do código no nível do kernel.
A desreferência do ponteiro NULL usada no exploit foi corrigida em outubro, mas como problemas semelhantes não são incomuns e foram tratados anteriormente como bugs, não vulnerabilidades, os desenvolvedores adicionarão proteção geral ao kernel do Linux para evitar ataques que manipulam a geração de “oops .”
No caso de uma tarefa, isso significa descartar a pilha de kernel existente e ir diretamente para make_task_dead, que chama do_exit. O kernel também postará no dmesg um log de “crash” e um rastreamento do kernel mostrando em que estado o kernel estava quando o erro ocorreu. Isso pode parecer uma escolha estranha quando a corrupção de memória ocorreu claramente; no entanto, a intenção é tornar os bugs do kernel mais fáceis de detectar e registrar sob a filosofia de que um sistema em execução é muito mais fácil de depurar do que um sistema inativo.
Em particular , o Kernel 6.2 inclui alterações para limitar o número máximo de “oops” . Após atingir o limite, que é definido como 10 mil oops por padrão (você pode alterá-lo através do parâmetro oops_limit se quiser), o kernel iniciará uma transição para o estado de “pânico”, seguida de uma reinicialização, que não permitirá o número de iterações necessárias para redefinir refcount para zero.
Também está planejado que a restrição seja transferida para ramificações do kernel lançadas anteriormente, mas ainda suportadas, bem como pacotes de kernel de distribuições populares.
Finalmente , se você estiver interessado em saber mais sobre isso, pode conferir os detalhes no link a seguir.
