Autor: Allele Security Intelligence

To access this blog post in English, click here.

Durante nossos projetos de pesquisa, precisamos investigar profundamente os subsistemas dos sistemas operacionais que são nosso alvo. Nesse processo, frequentemente encontramos outros problemas que não se alinham diretamente com nossos objetivos de pesquisa. No passado, nós os ignorávamos, mas recentemente decidimos iniciar um ciclo de contribuição, reportando e corrigindo essas falhas.

Especificamente para os problemas abordados nesta postagem, nós não apenas os reportamos, como também submetemos os patches de correção. Embora já tenhamos reportado vulnerabilidades e auxiliado em suas correções no passado, estes problemas marcam as primeiras instâncias em que somos os únicos autores dos patches submetidos.

Nesta postagem, detalhamos os problemas que reportamos e corrigimos no kernel do Linux.

Dos três itens reportados, dois são NULL pointer dereferences e o terceiro é um potencial out-of-bounds write no subsistema de arquivos Btrfs. Os NULL pointer dereferences poderiam permitir que usuários não privilegiados afetassem o funcionamento do sistema. Não investimos tempo significativo para tentar acionar a vulnerabilidade potencial de out-of-bounds no Btrfs, pois ela não era prioritária para nossos objetivos de pesquisa.

Embora a vulnerabilidade exista, ela requer uma condição que não parece trivial de ser alcançada. O mais notável sobre essa vulnerabilidade em particular é que ela é extremamente antiga, estando presente no kernel do Linux por mais de 17 anos. Ela havia sido identificada e houve uma tentativa de correção no passado, mas essa falha foi posteriormente esquecida. Apesar de o código vulnerável ter sido modificado diversas vezes desde a tentativa de correção original, a vulnerabilidade persistiu.

Todos os patches que submetemos já foram aplicados no upstream do kernel. A seguir, você encontrará todos os detalhes técnicos sobre cada uma das correções.

Introdução

No post anterior desta série realizamos a exploração da vulnerabilidade e, com isso, conseguimos escalar os privilégios ao obter a execução de uma shell como usuário ‘root'. Também tratamos um problema que surgiu no decorrer da exploração, conseguindo manter o sistema estável normalmente.

Porém, toda essa exploração foi feita com as mitigações desabilitadas. Ao montar o ambiente, na primeira parte da série de blog posts, o configuramos para que as mitigações fossem desabilitadas a fim de facilitar nossas análises e testes. Essa é uma prática bastante comum ao fazer pesquisa e exploração de vulnerabilidades.

Neste último post da série, agora que já exploramos a vulnerabilidade, vamos habilitar as mitigações, uma a uma, e fazer os bypasses delas, de modo que nosso exploit funcione mesmo em um ambiente com essas mitigações habilitadas. As mitigações que contornaremos serão Supervisor Mode Execution Prevention (SMEP) e Kernel Address Space Layout Randomization (KASLR). Já outras, como Supervisor Mode Access Prevention (SMAP) e Kernel Page Table Isolation (KPTI), não serão habilitadas e explicaremos o motivo ao final da postagem.