Vulnerabilidades do kernel Linux não chegam com aviso prévio às distribuições

 (openwall.com)
1 pontos por GN⁺ 3 시간 전 | 1 comentários | Compartilhar no WhatsApp
  • CopyFail, uma vulnerabilidade de escalonamento local de privilégios no kernel Linux, está entre as falhas “make-me-root” mais graves dos últimos kernels
  • O problema foi introduzido no commit 72548b093ee38a6d4f2a19e6ef1948ae05c181f7 da versão 4.14 e corrigido em 6.18.22, 6.19.12 e 7.0
  • As versões 6.19.12 e 6.18.22 foram lançadas em 11 de abril com o backport da correção, mas os kernels Longterm 6.12, 6.6, 6.1, 5.15 e 5.10 não receberam a correção naquele momento
  • A correção não faz clean apply em kernels mais antigos e, em situações que exigem distribuição imediata, um patch para desativar o módulo authencesn do IPSec pode ser usado como mitigação temporária
  • Vulnerabilidades do kernel Linux não chegam com aviso prévio às distribuições, a menos que quem as reporta as leve para a linux-distros ML; neste caso também não houve heads-up

Escopo de impacto e status da correção do CVE-2026-31431

  • CopyFail é uma vulnerabilidade de escalonamento local de privilégios no kernel Linux e está entre as falhas “make-me-root” mais graves dos últimos kernels
  • O problema foi introduzido no commit 72548b093ee38a6d4f2a19e6ef1948ae05c181f7 da versão 4.14 e corrigido respectivamente em 6.18.22, 6.19.12 e 7.0
  • commit de correção da 6.18.22
  • commit de correção da 6.19.12
  • commit de correção da 7.0
  • As versões 6.19.12 e 6.18.22 foram lançadas em 11 de abril já com o backport da correção incluído
  • Os kernels Longterm 6.12, 6.6, 6.1, 5.15 e 5.10 não receberam a correção naquele momento, e ela também não aparecia na fila stable upstream
  • Como o problema foi introduzido em 2017, é necessário verificar se kernels mais antigos também são afetados

Notificação prévia às distribuições e mitigação temporária

  • Essa correção não faz clean apply em kernels mais antigos
  • Tentou-se fazer o backport por ser uma situação que exigia distribuição imediata, mas algumas mudanças de API dificultaram avançar com segurança
  • Como mitigação temporária, pode-se usar um patch para desativar o módulo authencesn do IPSec, e mesmo para quem não é especialista em IPSec isso parece ser a “opção menos ruim”
  • 0001-crypto-disable-authencesn-module-for-CVE-2026-31431.patch: patch para desativar o módulo authencesn em resposta ao CVE-2026-31431
  • Vulnerabilidades do kernel Linux não chegam com aviso prévio às distribuições, a menos que quem as reporta as leve para a linux-distros ML
  • Neste caso, não houve heads-up via linux-distros ML

Leituras relacionadas

1 comentários

 
GN⁺ 3 시간 전
Comentários do Hacker News

  • Sam James, autor do texto linkado, é desenvolvedor do Gentoo
    De qualquer forma, isso foi quase catastrófico, e divulgar o exploit antes de as distribuições distribuírem as correções foi extremamente irresponsável
    Não dá para saber quantos provedores de shared hosting foram comprometidos por causa disso
    Também é preocupante que aparentemente não haja comunicação entre a kernel security team e os mantenedores das distribuições
    Você espera que o primeiro grupo avise o segundo, mas na prática parece que a responsabilidade recai sobre quem encontrou a vulnerabilidade

    • Não vejo problema em divulgar 30 dias após o patch entrar no alvo reportado
      Para referência, o Google Project Zero usa uma política semelhante de “90+30”: https://projectzero.google/vulnerability-disclosure-policy.h...
      O problema real é que não existe um canal de comunicação entre a kernel security team e os mantenedores das distribuições
      Quem descobre a vulnerabilidade não deveria ter a responsabilidade de reportar separadamente a todos os downstreams
      O time do kernel deveria ter informado à lista de responsáveis por segurança das distribuições a gravidade do patch e o cronograma de divulgação para 30 dias depois
    • Essa divulgação foi mais marketing do que segurança
      A própria página da divulgação traz frases como “Is your software AI-era safe?”, “Copy Fail was surfaced by Xint Code about an hour of scan time against the Linux crypto/ subsystem”, “[Try Xint Code]”
      É um jeito de fazer o produto parecer mais atraente quanto maior for a confusão
    • Como usuário e administrador, não concordo que isso tenha sido “extremamente irresponsável”
      A expressão Responsible Disclosure é como “Secure Boot”: um termo muito bem projetado linguisticamente, mas que na prática parece mais voltado à gestão de reputação das empresas e fundações que ficam entre mim e meu computador
      Elas estão mais interessadas em impedir que se diga “o RHEL é vulnerável” ou “o Ubuntu é vulnerável” do que em saber se o meu computador individual está vulnerável
      A vulnerabilidade já existe de qualquer forma, então prefiro ter a chance de conhecer o risco e mitigá-lo em vez de apenas esperar por uma correção silenciosa
      Acho que a divulgação imediata é a única escolha que não é irresponsável
    • Independentemente da posição sobre o processo de divulgação, qualquer hosting provider que tenha sido comprometido por isso já estava em uma situação estruturalmente perdida
      Rodar workloads de tenants que não confiam entre si sob um único shared kernel não é aceitável
      Kernel LPE não é algo raro, e este caso em especial só era particularmente simples e portátil; a capability bruta em si já é quase uma commodity de CNE
    • O Linux kernel não é adequado para ser usado como fronteira de segurança
      Se você faz shared hosting e quer evitar ser comprometido, precisa usar outras medidas, como gVisor ou VMs com Firecracker
      O Android é praticamente o único sistema importante que o usa como fronteira de segurança, e isso é mitigado por aprovação do usuário para instalar APKs, políticas rígidas de SELinux e seccomp, e hardening do GrapheneOS
      Neste caso, a mitigação também funcionou: https://discuss.grapheneos.org/d/35110-grapheneos-is-protect...

  • Não entendo por que dizem algo como “no caso de vulnerabilidades no Linux kernel, as distribuições não recebem aviso prévio a menos que o reporter leve isso diretamente à linux-distros ML”
    Exigir que o reporter coordene diretamente com as distribuições pressupõe um alto nível de conhecimento sobre o projeto Linux
    Quem reporta a vulnerabilidade não deveria ser responsável por trabalhar diretamente com todos os consumidores downstream do Linux kernel
    Levando essa lógica adiante, então também teria de entrar em contato diretamente com todos os fabricantes que usam Linux em seus equipamentos?
    Acho que o reporter já fez o suficiente ao divulgar de forma responsável ao Linux e esperar até que o patch entrasse
    Deveria haver pessoas dentro do projeto Linux com autoridade e responsabilidade sobre vulnerabilidades de segurança, e elas é que deveriam avisar os downstream distros

    • Isso vale ainda mais porque pedem explicitamente ao reporter que não avise primeiro as equipes das distribuições
      https://docs.kernel.org/process/security-bugs.html
      As such, the kernel security team strongly recommends that as a reporter of a potential security issue you DO NOT contact the “linux-distros” mailing list UNTIL a fix is accepted by the affected code’s maintainers and you have read the distros wiki page above and you fully understand the requirements that contacting “linux-distros” will impose on you and the kernel community.
    • O reporter teve tempo de verificar e mencionar distribuições específicas como Ubuntu/RHEL/SUSE no próprio site
      No mínimo, avisar as equipes de segurança dessas distribuições teria parecido a atitude responsável
    • É difícil considerar razoável que o reporter tenha criado um site citando explicitamente Ubuntu, RedHat, Amazon e SUSE e ainda assim não os tenha avisado
      Também não parece plausível que ele não soubesse que essas distribuições são downstreams do time do kernel
    • Pode não ser um requisito obrigatório, mas acho que todo mundo acabou sofrendo mais porque os reporters estavam mais interessados em notoriedade do que em remediação segura
    • É muito fácil descobrir como reportar esse tipo de problema de segurança para uma distro Linux
      Basta pesquisar no Google: https://share.google/aimode/eihDKXZJy94Z5lC1p
      Expor todo mundo a um exploit sem sequer pensar nisso é difícil de entender, e não me surpreenderia se em algumas jurisdições isso fosse considerado crime grave

  • A troca mais interessante sobre disclosure está neste link
    https://www.openwall.com/lists/oss-security/2026/05/01/3
    É a resposta de greg k-h: “não podemos avisar ninguém com antecedência, porque então teríamos de avisar todo mundo sobre tudo. Essa é a única política que os órgãos legais e governamentais concordaram em nos permitir operar”

    • Gosto do Linux, mas acho que isso é uma política idiota

  • Em vez de culpar o reporter, deveríamos exigir que o processo do kernel seja corrigido
    O Linux kernel não é mais um projeto de brinquedo, e há funcionários em tempo integral contratados por várias empresas
    Avisar as distribuições deveria ter sido tarefa deles, não de uma pessoa aleatória

    • Se em um post de blog de anúncio, essencialmente de marketing, você chegou ao ponto de citar distribuições específicas como afetadas, então dar um heads-up antes da divulgação era o comportamento apropriado e esperado
      Se não tivessem colocado menções como RHEL 14, provavelmente não teriam recebido tantas críticas
      Não estamos falando de um pesquisador individual de segurança ou da academia, mas de uma empresa de segurança com equipe profissional de comunicação apontando o dedo para mantenedores de distro
    • É verdade que distribuições e desenvolvedores do kernel precisam se comunicar sobre patches de alta severidade e agir rápido
      Mas pessoas reais podem ter sido prejudicadas porque o reporter não esperou que isso acontecesse, e essa responsabilidade é dele
    • Reportar uma vulnerabilidade e divulgar um exploit poderoso que qualquer pessoa pode usar são coisas completamente diferentes
      Soltar isso no mundo sem avisar primeiro as principais distros foi irresponsável

  • Para quem usa kernels em que AF_ALG é linkado diretamente ao kernel em vez de ser módulo, foi publicado um workaround baseado em eBPF: https://github.com/Dabbleam/CVE-2026-31431-mitigation
    Estou rodando isso em produção agora, ele mitiga o ataque e até agora não vi efeitos colaterais inesperados

  • Acho que nosuid e talvez nodev deveriam ser opções padrão de montagem de filesystem
    O /dev já é um devtmpfs especial, e o /dev mínimo do initrd poderia, se necessário, ser montado explicitamente com dev e suid na rootfs tmpfs do initrd
    Permitir que binários SUID simplesmente “existam” em qualquer lugar é um grande risco de segurança
    Quando você monta uma mídia externa, como verificar se os binários SUID naquele block device são maliciosos?
    Além disso, este exploit aparentemente só funciona se o usuário que executa o binário SUID também puder ler esse binário
    Não há motivo para usuários não root terem permissão de leitura em binários SUID
    O NixOS lida com isso corretamente
    O diretório normal de instalação de pacotes, /nix/store, não tem SUID, e como os pacotes não vazam para fora dele, é possível usar nosuid com segurança nos outros mountpoints
    A única exceção é o diretório de propósito único /run/wrappers.$hash, que guarda com segurança apenas wrappers SUID somente executáveis

    • Eu também odeio suid, mas aqui suid não é o problema essencial
      O bug explorado basicamente permite envenenamento arbitrário de page cache
      Nesse ponto, o jogo já acabou, e fazer patch em um programa suid pode até ser o jeito mais fácil de obter um root shell, mas não é o único
    • O exploit proof of concept serve literalmente apenas para demonstrar um vetor de ataque
      Há muitas outras formas
      Se o objetivo fosse apenas bloquear o exploit de prova de conceito, métodos mais simples como blacklist até serviriam, mas isso não tornaria o sistema mais seguro
      Com essa vulnerabilidade, é possível manipular o page cache
      Dá para manipular o ld.so para colocar hooks em chamadas de sistema arbitrárias, mudar o uid para 0, ou escalar privilégios de várias outras maneiras
      O mount point não tem relação com esse problema
      Claro, impedir suid em áreas graváveis pelo usuário e impedir leitura de arquivos suid é sempre uma boa ideia, mas por outros motivos
      O NixOS também não corrige essa vulnerabilidade e é vulnerável como qualquer outra distribuição
    • Sem permissão de leitura, não é possível executar o binário, e isso faz sentido
      Para executar um binário, ele precisa ser lido do disco e carregado em memória
      Na prática, se você tiver permissão de leitura em um binário específico, mas não permissão de execução, ainda pode executá-lo chamando o linker diretamente
      Por exemplo, chamar /bin/ld.so.1 /path/to/binary faz com que o linker leia e carregue o binário e então salte para o entry point sem chamar exec()

  • O link abaixo do Bleeping Computer traz possíveis medidas até que o patch fique pronto
    https://www.bleepingcomputer.com/news/security/new-linux-cop...

    • Esse workaround só se aplica a kernels em que o código afetado foi compilado como módulo
      RHEL, Fedora e Gentoo estão todos configurados para compilar esse código diretamente no kernel
      Sem patch ou mudança de configuração, como o Sam sugeriu em relação ao Gentoo, essas distribuições continuam vulneráveis
    • No RedHat e em distribuições derivadas, o código afetado é compilado estaticamente em vez de como módulo, então essa mitigação não funciona

  • O NixOS também não recebeu aviso
    https://discourse.nixos.org/t/is-nixos-affected-by-copy-fail...

    • Nenhuma distribuição recebeu aviso

  • O Hyperbola GNU estava seguro porque ainda usa Python 3.8 por razões políticas e de estabilidade

  • O Ubuntu já lançou patch, e os testes foram concluídos antes e depois do patch