1 pontos por GN⁺ 6 시간 전 | 1 comentários | Compartilhar no WhatsApp
  • Segundo o título no Hacker News, 432 CVEs do kernel Linux foram divulgados nas últimas 24 horas, mas atualmente não é possível verificar os detalhes individuais na página de aviso
  • A página de aviso aplica o procedimento antibot Anubis para evitar interrupções do servidor e restrições de acesso a recursos causadas por coleta massiva na web
  • Com prova de trabalho (Proof-of-Work) da família Hashcash, mantém baixo o ônus para acessos comuns enquanto aumenta o custo acumulado da coleta em massa
  • Esse método é uma solução temporária usada até que haja uma técnica para identificar navegadores headless
  • Recursos modernos de JavaScript são necessários, e plugins que os bloqueiam, como o JShelter, devem ser desativados nesse domínio para permitir o acesso

Estado atual da página de avisos de CVE

  • O título no Hacker News afirma que 432 CVEs do kernel Linux foram divulgados nas últimas 24 horas, mas a página fornecida não contém lista de CVEs nem detalhes
  • Em vez disso, é exibida apenas uma tela de cálculo de prova de trabalho com dificuldade 4

Como o Anubis funciona e suas limitações

  • A prova de trabalho da família Hashcash impõe uma carga computacional desprezível a cada acesso individual, mas gera custo acumulado para coleta em larga escala
  • No futuro, o objetivo é identificar navegadores headless por fingerprinting, por exemplo pelo modo de renderização de fontes, para não exibir a página de prova de trabalho a usuários legítimos
  • Recursos modernos de JavaScript exigidos pelo Anubis podem ser bloqueados por ferramentas como o JShelter, então é necessário desativar esse plugin para o domínio em questão para conseguir acessar

1 comentários

 
GN⁺ 6 시간 전
Comentários no Lobste.rs
  • CVE não é a vulnerabilidade em si, mas um identificador; ele pode ser atribuído quando uma vulnerabilidade real é descoberta

    • Demorei para entender a intenção, mas acho que o título deveria ter sido 432 vulnerabilidades no kernel Linux
  • O projeto do kernel Linux já afirmou várias vezes que considera a maioria dos bugs como candidatos a CVE, exceto correções de desempenho, correções de bugs de hardware e corrupção de sistema de arquivos

    http://www.kroah.com/log/blog/2026/01/02/linux-kernel-security-work/

    http://www.kroah.com/log/blog/2026/02/16/linux-cve-assignment-process/

    • A equipe de segurança do kernel não tem como saber todos os lugares e formas em que o kernel é usado, e isso também é um resultado peculiar de o kernel Linux ter se tornado sua própria CVE Numbering Authority (CNA)
      O sistema CVE foi originalmente criado para produtos, então não se encaixa muito bem em um kernel de sistema operacional usado como componente em vários produtos. Idealmente, CachyOS, o fabricante de uma câmera com kernel embarcado e a Red Hat deveriam avaliar de forma independente se o mesmo bug é candidato a CVE em seus respectivos contextos
      Mas, se fosse assim, poderia haver um CVE para cada um de 300 modelos de câmera, 300 modelos de roteadores/servidores de arquivos que se comportam de forma peculiar ao inserir um USB, e dezenas de consoles retrô de emulação de jogos que usam cartão SD; por isso, mesmo sendo estruturalmente estranho, gerenciar isso no nível do componente parece melhor para o ecossistema como um todo
    • Bugs de corrupção de sistema de arquivos também podem ser vistos como candidatos a CVE
  • Fico curioso para saber se há alguma vulnerabilidade especialmente interessante entre elas

  • Uma parte considerável dos itens começa com a frase “A seguinte vulnerabilidade foi corrigida no kernel Linux

  • Não resisti e pedi a um LLM para criar nomes chamativos para cada CVE
    https://git.infradead.org/~rw/cvenames-2026-07-19.html

  • Ao olhar o primeiro item relacionado a XFS, parece que o problema só ocorre com um log manipulado
    Para uma exploração real, parece que seria preciso colocar o sistema de arquivos offline e escrever diretamente no dispositivo de bloco onde o log está armazenado; nesse caso, pareceria necessário ter privilégios de root ou acesso físico e a capacidade de desligar o sistema. Fico em dúvida se entendi errado o log do XFS

    • Talvez isso não seja uma ameaça para servidores com monitoramento físico e que não fazem montagem automática de pendrives ou cartões SD, mas pode afetar outros ambientes Linux
      Por exemplo, alguém pode entregar um cartão SD dizendo que tem “fotos”, mas com um sistema de arquivos XFS malicioso; ao conectá-lo em casa, uma cadeia de exploração da vulnerabilidade poderia ser executada. Montar um sistema de arquivos também deveria ser uma operação segura, assim como abrir um arquivo de imagem
    • O fato de a probabilidade ser baixa não significa que não seja uma vulnerabilidade potencial, e o ambiente de uso também importa
      Pode haver dispositivos do tipo quiosque que fazem montagem automática ao conectar um dispositivo de armazenamento, e problemas que normalmente parecem irreais podem se tornar ataques viáveis quando combinados com várias falhas ou com um ambiente específico
    • Em uma instalação de hospedagem por colocação, um ataque conectando USB ou HDD a um servidor provavelmente teria algo como 95% de chance de sucesso
      Mesmo que isso apareça nas câmeras, talvez seja difícil verificar com clareza que ele não foi conectado a outro servidor no mesmo rack