Em março de 2022, um pesquisador chamado Max Kellerman divulgou publicamente uma vulnerabilidade do Kernel Linux (apelidada de Dirty Pipe, por suas semelhanças com a notória exploração Dirty Cow, que afeta versões mais antigas do kernel), que permitia que invasores sobrescrevessem arbitrariamente arquivos no sistema operacional. A vulnerabilidade foi divulgada em uma postagem no blog escrito por Max Kellerman logo após a disponibilização dos patches.

As substituições de arquivos arbitrários no nível do kernel podem ser facilmente aproveitadas para escalar privilégios na máquina (ou seja, para obter privilégios de administrador ou “root“). Esta é uma vulnerabilidade devastadora, ainda mais por seu alcance: todos os dispositivos que executam uma versão vulnerável do kernel Linux (incluindo telefones Android) são afetados!

Timeline da vulnerabilidade, de sua descoberta à sua divulgação

Visão geral

Devido à sua natureza de baixo nível, qualquer discussão aprofundada das vulnerabilidades do kernel rapidamente se torna bastante complicada. A demonstração aqui se dará em termos mais amplos. Para detalhes mais aprofundados, recomendo a postagem original no blog de Max Kellerman.

É importante observar que o Dirty Pipes foi corrigido nas versões 5.16.11, 5.15.25 e 5.10.102 do kernel Linux, portanto, se você usa ou gerencia algum dispositivo Linux (ou Android), certifique-se de que eles estão executando um kernel superior aos destas versões!

Teoria

Para entender como o Dirty Pipe funciona, devemos primeiro entender como o Kernel Linux gerencia a memória.

A menor unidade de memória controlada pela CPU é chamada de página – geralmente cerca de 4Kib em sistemas modernos. A grosso modo, as páginas são usadas ao ler e gravar arquivos do disco, embora tenham muitos outros usos. A parte do kernel que gerencia as páginas é chamada de cache de página.

Quando um processo tenta abrir um arquivo, o kernel o carrega em páginas que são então disponibilizadas para o processo userland. Esse acesso à área de usuário pode ser concedido copiando-se na memória do espaço do usuário ou mantendo as páginas no espaço do kernel, mas tornando-as acessíveis por meio de chamadas de sistema (funções efetivamente especiais que são usadas para interagir com o kernel).

Ok, então o que isso tem a ver com Dirty Pipe? A vulnerabilidade surge por causa de como o kernel implementa pipes.

Você provavelmente estará familiarizado com a ideia de anonymous pipes – eles são apresentados na maioria das linguagens de shell e permitem que você passe dados entre dois processos, geralmente com o caractere pipe (|). Os pipes são caracterizados por terem duas extremidades — uma para leitura e outra para escrita; você pode ver isso por si mesmo na maneira como os pipes anônimos pegam a saída padrão de um processo e a escrevem em um pipe onde ela pode ser lida pela entrada padrão do próximo programa na cadeia.

Voltando ao tópico: o kernel do Linux fornece uma chamada de sistema chamada splice(), que é efetivamente um atalho projetado para acelerar o processo de enviar o conteúdo de um arquivo para um pipe. Essa otimização é obtida movendo as referências para as páginas que armazenam o conteúdo do arquivo, em vez de mover a totalidade dos dados. Em outras palavras, splice() nos permite apontar um pipe para uma página que já está carregada na memória, contendo uma seção de um arquivo originalmente aberto por um processo solicitando acesso somente leitura. Ao emendar uma página no pipe e depois escrever nossos próprios dados arbitrários no pipe, podemos substituir o conteúdo da página!

Não é tão simples, no entanto; ainda nos falta uma peça final do quebra-cabeça. Normalmente, quando você grava em um pipe depois de emendar um arquivo, um novo pipe_buffer é criado para evitar sobrescrever os dados emendados. Então, como forçamos o kernel a nos permitir sobrescrever a(s) página(s) relevante(s)?

Este é o verdadeiro ponto crucial da vulnerabilidade, e tudo pode ser rastreado até dois commits no kernel do Linux:

• Um bug foi introduzido no Linux Kernel v4.9 (2016) que permitia a criação de pipes com sinalizadores arbitrários. Nenhuma das flags disponíveis na época era perigosa, então isso não era um problema, até que…
• O Kernel Linux v5.8 (2020) adicionou um novo sinalizador — PIPE_BUF_FLAG_CAN_MERGE. Em termos simples, esse sinalizador informa ao kernel que a página pode ser atualizada sem forçar uma reescrita dos dados.

Resumindo: temos um sinalizador que nos permite dizer ao kernel que não há problema em sobrescrever os dados em uma página, temos um bug que nos permite especificar sinalizadores arbitrários para um pipe e temos uma chamada de sistema que inadvertidamente nos permite apontar pipes em buffers de página que foram abertos como somente leitura. O que poderia dar errado?

Simplificando, o exploit primeiro abre um arquivo de destino com o sinalizador somente leitura definido — para fazer isso, devemos escolher um arquivo que tenhamos permissão para ler. O exploit então prepara um pipe de uma maneira especial, forçando a adição do sinalizador PIPE_BUF_FLAG_CAN_MERGE. Em seguida, ele usa splice() para fazer o pipe apontar para a seção desejada do arquivo de destino. Finalmente, ele grava quaisquer dados arbitrários que o usuário especificou no pipe, substituindo a página de destino por mérito do sinalizador PIPE_BUF_FLAG_CAN_MERGE.

Os efeitos

Então, o que isso tudo significa? Em resumo, significa que, com o código correto, podemos sobrescrever arbitrariamente qualquer arquivo no sistema, desde que possamos abri-lo para leitura. Em outras palavras: se nosso usuário tiver acesso de leitura sobre o arquivo (independentemente de outras permissões ou mutabilidade), também podemos escrever nele. Curiosamente, isso também se aplica a sistemas de arquivos somente leitura, ou arquivos protegidos de outra forma que o kernel normalmente nos impediria de gravar; explorando a vulnerabilidade do kernel e contornando os métodos de gravação “usuais”, também contornamos essas proteções. É importante notar que as mudanças não serão realmente permanentes até que o kernel escolha recuperar a memória usada pela página (no ponto em que a página é despejada no disco). Reiniciar o dispositivo ou limpar o cache da página manualmente antes que o kernel recupere a memória reverterá o arquivo de volta ao seu conteúdo original.

Remediações

Felizmente, a correção para esta vulnerabilidade é muito simples: atualize seu kernel.

Versões corrigidas do Kernel Linux foram lançadas para as principais versões de kernel suportadas — especificamente, a vulnerabilidade foi corrigida nas versões 5.16.11, 5.15.25 e 5.10.102 do kernel Linux.

Certifique-se de aplicar atualizações a todos os seus dispositivos Linux (incluindo qualquer Android) assim que os patches de segurança forem lançados.

A Exploração

Uma máquina Linux com Kernel vulnerável foi disponibilizada, contendo uma cópia do código de exploração da prova de conceito original de Max Kellerman (originalmente encontrado na postagem do blog de divulgação) em /Exploit/PoC/poc.c. Uma vez compilado, esse exploit nos dá muito controle sobre como abusamos da vulnerabilidade do Dirty Pipe. Ele nos permite especificar o arquivo que queremos substituir, o deslocamento em que gostaríamos de substituí-lo e o conteúdo que gostaríamos de inserir.

Tendo em mente que o exploit não nos permite criar arquivos (só podemos sobrescrever informações em arquivos existentes), primeiro precisamos encontrar um arquivo que nosso usuário possa ler, mas que ainda nos permita elevar nossos privilégios. A escolha óbvia e fácil, nessas condições, é /etc/passwd.
Embora os hashes de senha geralmente sejam armazenados no acesso restrito /etc/shadow nos sistemas Linux modernos (em vez de serem armazenados tradicionalmente em /etc/passwd), a maioria das variantes do Linux ainda verifica se os hashes de senha da conta são fornecidos em /etc /passwd. Isso significa que podemos inserir um usuário com permissões de root e um hash de senha conhecido diretamente no arquivo passwd!

Vamos gerar um hash de senha e formar uma entrada passwd válida antes de prosseguir. Escolha uma senha e use o comando openssl para criar um hash SHA512Crypt de sua senha escolhida:
Finalmente, insira seu nome de usuário e o hash, neste modelo de entrada de senha: USERNAME:HASH:0:0::/root:/bin/bash.

A entrada deve ficar mais ou menos assim:

eximia:$6$THM$eRD0Ur0SZuwDLSwf9Lb2vyC2T6/PtQUA/B0Ssm6/jsiBtpSvc6QLjhFF0XNM8odgfkxMnC4oczGuvEomrVRfz0:0:0::/root:/bin/bash

Como estamos substituindo as entradas existentes no arquivo de senhas, também precisamos adicionar uma nova linha no final de nossa entrada. Isso garante que evitemos corromper nossa entrada com quaisquer resquícios do conteúdo anterior da linha.

Nosso conteúdo final deve, portanto, ser algo assim (aspas simples incluídas):

'eximia:$6$THM$eRD0Ur0SZuwDLSwf9Lb2vyC2T6/PtQUA/B0Ssm6/jsiBtpSvc6QLjhFF0XNM8odgfkxMnC4oczGuvEomrVRfz0:0:0::/root:/bin/bash
'

Temos então o arquivo (/etc/passwd) e o conteúdo (a entrada passwd) — tudo o que precisamos agora é o deslocamento. O deslocamento é onde, no arquivo, o exploit deve começar a escrever – em outras palavras, qual parte do arquivo é substituída.
A vulnerabilidade não nos permitirá anexar ao arquivo, então teremos que escolher uma conta e sobrescrevê-la. Falando de forma realista, dado o tamanho de nossa entrada passwd (incluindo hash), isso provavelmente substituirá várias contas. Examinando o arquivo passwd, a conta games se destaca como uma boa candidata e que podemos nos dar ao luxo de destruir por alguns minutos. Podemos usar grep com a opção -b para encontrar o deslocamento da conta desde o início do arquivo:

O deslocamento é revelado como sendo 189, dando-nos a peça final do nosso quebra-cabeça e o exploit pode então ser compilado, usando gcc

Antes de executarmos o exploit, é muito importante que façamos backup do arquivo /etc/passwd. Esta é uma exploração disruptiva que causará danos ao sistema (pelo menos por um tempo); com o backup do arquivo passwd, podemos facilmente reverter o dano após a conclusão da exploração.

Como a EximiaCo pode lhe ajudar

O vídeo ilustrando este ataque está em tempo real e, inicialmente, nos chama a atenção a rapidez e a facilidade com que um host é completamente tomado de assalto, ainda mais por um exploit público, disponível a qualquer pessoa. O dano resultante deste ataque pode ser catastrófico para uma companhia, dependendo do alvo afetado.

A grande recomendação aqui é sobre o seu programa de gestão de vulnerabilidades. Invista tempo na construção, detalhamento e atualização de seu inventário de ativos. Se possível, disponha de ferramentas de gestão de vulnerabilidades automatizadas e de um corpo técnico qualificado e atualizado. Atualizações e patches de segurança devem ser prioritários.

A EximiaCo conta com uma divisão de Segurança Cibernética altamente treinada, e disponibiliza o programa de CSO as a Service para ajudar você a elevar o nível de excelência em segurança cibernética.