Exploração de referências nulas no kernel do Linux
Recentemente foi divulgada a notícia de que o pesquisadores da equipe do Google Project Zero desenvolveram un método para explorar vulnerabilidades no kernel do Linux causado por desreferenciar o ponteiro NULL.
Até agora, os problemas em kernel relacionado com ponteiros NULL desreferenciados não receberam a devida atenção, uma vez que era considerado irreal transformar tais problemas em ataques que levariam ao escalonamento de privilégios ou à execução do próprio código (proibido mapear processos não privilegiados na região inferior do espaço de endereçamento).
Como uma regra geral, tais erros levam à geração de avisos de oops pelo kernel, após o que 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 é baseado no tratamento de estados "oops", o que pode resultar em um aumento no valor do contador de referência (refcount), que por sua vez pode fazer com que o contador estoure e libere a 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 desreferenciamento nulo 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 núcleo não interrompe toda a execução por um oops; em vez disso, o kernel tenta se recuperar da melhor maneira possível e continua a execução.
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 na exploração 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 "ops". 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, você pode verificar os detalhes no link a seguir