OpenBSD tem um use-after-free que permite escalada local de privilégios para root

Artigo original ↗ Discussão no Hacker News ↗

Vulnerabilidade e impacto

  • A CVE descreve um use-after-free em sys/kern/sysv_sem.c (semafóros SysV) no OpenBSD ≤7.9 que permite escalada local de privilégios (LPE) para root.
  • Trata-se de um UAF de troca de contexto após tsleep em sys_semget().
  • Comentadores enfatizam que é sério, mas não um “buraco remoto”.
  • A possibilidade de acesso a partir de processos em sandbox é discutida; uma implementação ligada de pledge(2) sugere que daemons base em sandbox geralmente não conseguem usar essas syscalls.

Descoberta e auditoria assistida por IA

  • O bug parece ter sido descoberto na iniciativa “Patch The Planet” (modelos da OpenAI + Trail of Bits) que analisa projetos de código aberto.
  • Alguns inferem que ele foi corrigido primeiro como um bug genérico; só depois seu potencial de LPE foi reconhecido, possivelmente pela ferramenta de IA. Isso é apresentado como um palpite, não como algo confirmado.
  • Estatísticas do próprio Patch The Planet: Linux 24 LPEs, FreeBSD 7, OpenBSD 1, além de muitos problemas não relacionados a LPE.
  • Há debate sobre se auditorias baseadas em IA são economicamente vantajosas em comparação com financiar pesquisa tradicional de segurança.

Histórico de segurança do OpenBSD e “marketing”

  • O slogan do OpenBSD “apenas dois buracos remotos na instalação padrão” é ao mesmo tempo elogiado por ser tecnicamente preciso e criticado por ser seletivo:
    • A instalação padrão é mínima e tem a maioria dos serviços desativados, então os sistemas do mundo real diferem.
    • Ainda assim, padrões mínimos e hardening agressivo (pledge, unveil, W^X, ASLR etc.) são vistos como forças genuínas.
  • Alguns argumentam que o OpenBSD às vezes minimiza ou filtra o que chama de “bugs de segurança”, em parte porque muitas issues reportadas são superestimadas ou impraticáveis.

Comparações com Linux/FreeBSD e tamanho de código

  • Vários comentadores associam mais bugs em Linux/FreeBSD a:
    • Bases de código maiores e mais recursos/drivers.
    • Maior rotatividade de desenvolvimento.
  • Comparações por linhas de código são citadas; menos LOC é associado a menos bugs, embora as implicações exatas para a segurança sejam debatidas.

Relevância da escalada local de privilégios

  • Uma visão: LPEs importam menos para implantações típicas de servidores OpenBSD que não executam código não confiável.
  • Contraponto: LPEs tornam-se críticas quando encadeadas com RCE ou ataques à cadeia de suprimentos; são chave em defesa em profundidade.

Discussão sobre Rust e segurança de memória

  • Muitos observam que o modelo de ownership do Rust é projetado para prevenir UAF, então uma versão direta desse bug provavelmente nem compilasse.
  • Outros enfatizam a realidade do kernel:
    • Grandes partes precisam ser unsafe, especialmente em torno de interrupções, DMA e primitivas de baixo nível.
    • A segurança do Rust “seguro” depende da correção do código unsafe subjacente.
  • O consenso: Rust reduz significativamente certas classes de bugs, mas não elimina magicamente vulnerabilidades de kernel.

Compensações de design e recursos do OpenBSD

  • Vários argumentam que o bom resultado do OpenBSD (uma LPE) reflete cultura, engenharia cuidadosa e um conjunto deliberado de recursos.
  • Há debate sobre se o OpenBSD é realmente “mínimo”:
    • Alguns dizem que ele omite grandes subsistemas (por exemplo, Bluetooth, sistemas de arquivos “modernos” como ZFS) em parte por segurança e manutenção.
    • Outros observam que o sistema base é na verdade rico (por exemplo, daemons BGP, ferramentas de rede), apenas com uma filosofia e escopo diferentes.
  • A falta de journaling/ZFS para roteadores é questionada; defensores apontam para FFS totalmente síncrono e perguntam que dados de roteador realmente precisam sobreviver a uma queda de energia.

Ferramentas de DNS e tangente sobre OpenWRT

  • Um fio separado critica o histórico recente de vulnerabilidades do dnsmasq; alguns o removeram de seus sistemas.
  • O uso padrão do dnsmasq no OpenWRT é questionado; alternativas como Unbound (com ou sem NSD) são sugeridas, mas o papel “tudo em um” de DNS/DHCP/BOOTP/TFTP do dnsmasq torna a substituição não trivial.