Pesquisa expõe bug de 37 anos no kernel do OpenBSD que virava acesso root

A empresa de segurança ofensiva Calif publicou em 16 de outubro de 2026 os detalhes de uma vulnerabilidade que, segundo o relato, remonta a cerca de 37 anos: um contador de anexos de memória compartilhada definido como um short com sinal de 16 bits no código original do BSD. O pesquisador Andrew Griffiths descreve a cadeia completa no texto Big Fish: Exploiting a 37-Year-Old Kernel Bug in OpenBSD.

A falha foi reportada à OpenBSD ainda neste ano, junto de patches sugeridos, e já está corrigida via duas errata oficiais do projeto, a 026 e a 018. O caso interessa a quem desenvolve porque mostra como uma decisão de tipo de dado tomada décadas atrás pode sobreviver a sucessivas auditorias de segurança sem ser notada.

Um contador que não devia estourar

O problema mora no subsistema de memória compartilhada do estilo SysV. Cada vez que um processo anexa um segmento, um contador de anexos é incrementado. Esse contador, herdado das fontes originais do BSD, é um inteiro de 16 bits com sinal, com limite máximo de 32.767.

Fazer fork() repetidamente em um processo com registros de anexo de memória compartilhada consegue empurrar esse contador além do limite, fazendo-o dar a volta (wrap) para um valor negativo. Esse integer overflow, por si só, já abre caminho para um use-after-free via condição de corrida. Combinado a uma segunda falha, uma escrita fora dos limites (out-of-bounds write) no kernel, o resultado é escalação de privilégio local até root.

A cadeia de exploração, passo a passo

O ponto mais chamativo do trabalho da Calif não é só achar o bug, é conseguir explorá-lo de ponta a ponta num sistema com KARL, SMAP e SMEP ativados, mitigações do próprio OpenBSD, sem depender de nenhuma vulnerabilidade de vazamento de informação para descobrir endereços de memória. Na prática, a cadeia descrita segue estes passos:

1. Mapear 127 segmentos de memória compartilhada SysV, desmapeá-los com munmap() e fazer fork() de 259 processos para levar o contador de anexos a -32.643.
2. Usar sysctl(KERN_MALLOCSTATS) (campos como kb_total e kb_totalfree) para monitorar o heap e descobrir quando novas páginas são alocadas, permitindo um "heap grooming" preciso.
3. Vencer a condição de corrida usando IPC_RMID em um processo enquanto um processo auxiliar anexa um novo segmento de memória compartilhada com tamanho confuso.
4. Alinhar alocações de sockets IP e definir IP_MULTICAST_TTL com valor não padrão (2) para alocar de forma persistente uma struct ip_moptions de 16 bytes, cuja última palavra empacota dois contadores de 16 bits.
5. Disparar a escrita fora dos limites condicional (-1) para sobrescrever tanto o número de memberships quanto o máximo permitido.
6. Fechar o socket (close()) para percorrer os membros do grupo, disparando decrementos atômicos que alteram duas vezes o mapeamento auto-referencial de PTE, trocando-o de acesso de usuário para acesso de supervisor, e assim conseguir execução de código em modo kernel sobrescrevendo um ponteiro de kernel previsível.
7. Limpar a contabilidade de memória compartilhada e restaurar o ponteiro de kernel sobrescrito para obter um shell root.

Griffiths resume o achado assim:

Esse é o resumo da história; a versão completa é mais interessante, incluindo o histórico da vulnerabilidade, já que um shm_nattch curto remonta a cerca de 37 anos atrás, nas fontes originais do BSD.

That's the short of the matter, the longer version is more interesting, including the history of the vulnerability, as a short shm_nattch can be traced back ~37 years ago, in the original BSD sources.Andrew Griffiths, pesquisador da Calif

Em termos de primitivas de exploração, o texto classifica o resultado como um clássico "write-what-where": a escrita veio de um TAILQ_REMOVE, o "o quê" foi um mapeamento de memória de usuário promovido a modo supervisor (contornando SMAP e SMEP), e o "onde" foi um ponteiro de kernel em posição previsível.

Por que o ponteiro era previsível

O KARL do OpenBSD relinka o binário do kernel a cada boot, randomizando endereços de funções e de dados. O problema é que os alocadores de memória do kernel continuam determinísticos: tanto o alocador de boot quanto o alocador best-fit não têm randomização de endereço base.

Isso significa que alocações feitas no início do boot caem sempre no mesmo lugar em um mesmo hardware, boot após boot. Quando essas estruturas previsíveis guardam ponteiros de função, viram alvo ideal. O exploit mira especificamente os manipuladores de ioctl das interfaces lo0 e enc0: um é sobrescrito para desviar o fluxo de execução, o outro serve para restaurar o ponteiro original depois.

O que o OpenBSD (e qualquer kernel de longa vida) pode fazer a mais

Além das duas errata já publicadas, a Calif sugere um conjunto de mitigações que vão além do patch pontual:

• Safe-unlinking: verificar os invariantes de listas duplamente encadeadas antes de executar a escrita de desvinculação; se violados, chama abort() ou panic() em vez de corromper memória. FreeBSD e NetBSD já têm essa técnica implementada em sys/queue.h.
• Randomização do mapeamento PTE auto-referencial: sortear um slot de PML4 (320 + (random_byte & 127)) no boot, tornando PTE_BASE uma expressão calculada em tempo de execução em vez de um endereço fixo.
• Alocador de kernel não determinístico: randomizar o endereço base das alocações no boot (praticamente sem custo) e, adicionalmente, a ordem de alocação em tempo de execução (com algum overhead).
• Sanitizers de compilador em produção: a Calif já sugeriu ao FreeBSD habilitar o array bounds sanitizer (parte do UBSan) em builds de release, depois de reportar 21 problemas que ele teria capturado, alguns com impacto de escalação de privilégio local.
• Alloc Tokens: um recurso de compilador ainda em desenvolvimento para isolar alocações que contêm ponteiros das que não contêm, dificultando que um overflow numa alocação sem ponteiros vire controle de fluxo.

O que isso muda pra quem mantém sistema de longa vida

O OpenBSD é, historicamente, uma das bases de código mais auditadas que existem, com décadas de revisão proativa, substituição de APIs inseguras e hardening sistemático. Mesmo assim, uma decisão de tipo tomada há quase 40 anos sobreviveu intacta até ser encontrada em 2026.

Isso é um lembrete direto para quem trabalha com código que atravessa gerações: um contador short com sinal, parecendo inofensivo isolado, vira primitiva de corrupção de memória quando combinado com um caminho de uso que ninguém previu quando o tipo foi escolhido. Auditoria manual de código antigo tende a revisar o que mudou recentemente, não premissas antigas que nunca foram questionadas.

A Calif termina o texto apontando para o cenário que vem a seguir: descoberta de vulnerabilidades assistida por IA↳Inteligência artificial440 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025IA generativa e a urgência de reconstruir nossa relação com a verdadeAI · jun 2025Ver tudo em AI → deve acelerar o ritmo em que bugs como esse são encontrados, o que torna mitigações de classe inteira (como sanitizers em build de produção e randomização de alocador) mais urgentes do que depender só de patch reativo por CVE. Para times que mantêm kernels, drivers ou qualquer código C de vida longa, o caso é argumento concreto para rodar UBSan e equivalentes também em produção, não só em CI de desenvolvimento.

Fonte: Hacker News