CVE-2022-0847

Dirty Pipe é uma falha de inicialização incompleta no subsistema de pipes do kernel Linux que permite a um usuário local sem privilégios sobrescrever dados em páginas do page cache de arquivos somente leitura — incluindo arquivos pertencentes a root, binários SUID e montagens read-only. O impacto prático é escalada de privilégios trivial e confiável, sem necessidade de condição de corrida, o que a torna mais fácil de explorar que a Dirty COW (CVE-2016-5195), sua prima espiritual de 2016.

A falha está nas funções copy_page_to_iter_pipe e push_pipe, usadas quando o kernel cria novos buffers dentro de um pipe. O campo "flags" da struct pipe_buffer não era reinicializado ao alocar um novo buffer nessas rotinas, herdando valores obsoletos de um uso anterior do mesmo buffer. Especificamente, a flag PIPE_BUF_FLAG_CAN_MERGE — que indica que dados podem ser "mesclados" (escritos) diretamente numa página já existente no pipe — podia permanecer ativa por engano.

O problema (CWE-665, Improper Initialization) foi introduzido no kernel 5.8, quando a lógica de splice/pipe foi reescrita para usar referências de página em vez de cópias, uma mudança de performance que eliminou uma verificação implícita de permissão de escrita. Como a flag CAN_MERGE não distingue se a página no pipe é uma cópia interna ou uma referência direta a uma página do page cache de um arquivo em disco, o kernel aceita uma escrita nessa página sem validar se o arquivo subjacente é gravável pelo processo chamador.

O atacante controla o conteúdo escrito e o deslocamento dentro do arquivo-alvo (dentro dos limites do que splice() permite manipular), desde que consiga fazer com que uma página do arquivo termine referenciada dentro de um pipe cujo buffer tenha a flag indevidamente setada. Não há uso de memória fora de limites nem corrupção de estruturas do kernel — é puramente um erro de controle de acesso disfarçado de bug de inicialização.

A exploração é local, não requer autenticação privilegiada (PR:L no vetor reflete apenas a necessidade de uma conta local qualquer) e não exige interação de outro usuário. O pré-requisito real é: acesso de shell (ou execução de código) na máquina, kernel dentro da faixa vulnerável, e permissão de leitura sobre o arquivo-alvo — não é necessário poder escrever nele, essa é justamente a garantia que a falha quebra. Mecanicamente, o ataque usa uma sequência de chamadas envolvendo pipes e splice() para forçar um buffer de pipe a referenciar uma página do page cache do arquivo-alvo com a flag de merge indevidamente ativa, e então escrever nesse buffer — a escrita se propaga para a página real do arquivo em disco/cache.

Na prática documentada por pesquisadores e por provas de conceito públicas, isso foi usado para modificar arquivos de sistema protegidos (como /etc/passwd), sequestrar binários SUID substituindo seu conteúdo por um payload controlado pelo atacante, e obter shell como root. A CISA lista a falha no catálogo KEV por exploração confirmada in-the-wild, e existe módulo Metasploit e múltiplos PoCs funcionais publicados poucos dias após a divulgação — a barreira técnica para exploração é baixa uma vez que se tem qualquer acesso local, incluindo containers mal isolados e ambientes Android (que usam kernels Linux e frequentemente ficam atrás no patch level).

A falha não afeta arquivos que o kernel bloqueia por outros mecanismos (ex.: proteções de imutabilidade via chattr +i, ou montagens com opções específicas que impedem mmap gravável), mas a maioria dos sistemas em produção não usa essas proteções como padrão.

A correção definitiva é atualizar o kernel. O fornecedor (mantenedores do kernel Linux) corrigiu a falha nas versões 5.16.11, 5.15.25 e 5.10.102, com backports subsequentes feitos por cada distribuição (RHEL, Ubuntu, Debian, SUSE, e fabricantes de dispositivos Android via boletins de segurança). Não existe flag de configuração, parâmetro de sysctl ou opção de montagem que neutralize a falha sem patch — é um bug de lógica no caminho de código do pipe, não um recurso que pode ser desativado seletivamente.

Como paliativo real na ausência de patch imediato, é possível restringir a superfície reduzindo quem pode executar splice()/vmsplice() via seccomp-bpf ou perfis de LSM (AppArmor/SELinux) customizados, mas isso tem custo operacional alto: splice é usado por ferramentas comuns (netcat, proxies, containers) e bloqueá-lo pode quebrar funcionalidade. Monitoramento de integridade de arquivos (AIDE, Tripwire) sobre binários SUID e arquivos críticos de sistema serve como detecção compensatória, não como prevenção.

Mito a descartar: reiniciar serviços, remontar filesystems como read-only no nível de bloco, ou usar contêineres sem privilégios não elimina o risco — a falha está no kernel do host e afeta qualquer processo com acesso de leitura ao arquivo, independentemente de namespaces, exceto quando o isolamento de kernel entre host e convidado é real (máquinas virtuais completas, não apenas containers compartilhando kernel).

Como o vetor é puramente local e a exploração ocorre inteiramente em memória via chamadas de sistema padrão (pipe, splice, vmsplice, write), não há assinatura de rede e a maioria dos PoCs não deixa rastro óbvio em logs de aplicação. O sinal mais confiável é comportamental: monitoramento de syscalls via auditd/eBPF observando sequências atípicas de splice()/vmsplice() por processos não privilegiados seguidas de escrita em arquivos aos quais o processo não deveria ter permissão de gravação, e verificação de integridade (hash) de binários SUID e arquivos de sistema críticos para detectar modificação retroativa.

Na ausência dessas instrumentações, não há sinal confiável — é preciso assumir exposição com base na versão do kernel em uso, não em evidência de log.