Gpg.fail

• Um site que divulga várias vulnerabilidades de segurança relacionadas ao GnuPG, com links para páginas de descrição detalhada de cada falha
• O site lista diversos casos de problemas que ocorrem nos processos de assinatura PGP, criptografia e verificação de confiança
• Entre os principais itens estão ataques de texto claro, path traversal, erros no cálculo de hash, corrupção de memória e assinaturas forjadas
• O mantenedor menciona que está reescrevendo o site às pressas e que deve publicar slides, PoCs e patches em breve
• Um caso que evidencia a necessidade de uma verificação rigorosa da integridade de assinaturas e da cadeia de confiança em ferramentas de segurança open source

---

Visão geral do site

• gpg.fail é um site que reúne e divulga vulnerabilidades do GnuPG (implementação de OpenPGP)
  • Cada item leva, por meio de um link separado, a uma página com análise técnica detalhada
  • O mantenedor afirma: “deixei o código-fonte do site em casa e estou reescrevendo tudo; espere uma versão melhor amanhã”
• No topo do site há a frase “Slides, pocs and patches soon!”, antecipando a divulgação de mais materiais

Principais vulnerabilidades divulgadas

• Multiple Plaintext Attack on Detached PGP Signatures
  • Aponta a possibilidade de ataque de múltiplos textos claros em assinaturas PGP destacadas
• GnuPG Accepts Path Separators and Path Traversals in Literal Data "Filename" Field
  • O GnuPG aceita separadores de caminho e path traversal no campo de nome de arquivo dos dados literais
• Cleartext Signature Plaintext Truncated for Hash Calculation
  • Ocorre um problema de truncamento do texto claro durante o cálculo do hash
• Encrypted message malleability checks are incorrectly enforced causing plaintext recovery attacks
  • Verificações de maleabilidade da mensagem criptografada são aplicadas incorretamente, permitindo ataques de recuperação de texto claro
• Memory Corruption in ASCII-Armor Parsing
  • Pode haver corrupção de memória durante o parsing de ASCII-Armor
• Trusted comment injection (minisign)
  • Possibilidade de injeção de comentário confiável (trusted comment) no minisign
• Cleartext Signature Forgery in the NotDashEscaped header implementation in GnuPG
  • Possibilidade de falsificação de assinatura em texto claro na implementação do cabeçalho NotDashEscaped no GnuPG
• OpenPGP Cleartext Signature Framework Susceptible to Format Confusion
  • Vulnerável a confusão de formato (format confusion)
• GnuPG Output Fails To Distinguish Signature Verification Success From Message Content
  • Problema de saída em que o GnuPG não distingue o sucesso da verificação de assinatura do conteúdo da mensagem
• Cleartext Signature Forgery in GnuPG
  • Possibilidade de falsificação de assinatura em texto claro causada por erro no tratamento de byte NULL
• Radix64 Line-Truncation Enabling Polyglot Attacks
  • Truncamento de linha em Radix64 possibilitando ataques polyglot
• GnuPG may downgrade digest algorithm to SHA1 during key signature checking
  • O algoritmo de digest pode ser rebaixado para SHA1 durante a verificação de assinatura de chave no GnuPG
• GnuPG Trust Packet Parsing Enables Adding Arbitrary Subkeys
  • O parsing de pacotes de confiança permite adicionar subchaves arbitrárias
• Trusted comment Injection (minisign)
  • A vulnerabilidade de injeção de comentário confiável relacionada ao minisign é mencionada novamente

Planos futuros

• O mantenedor afirma que está trabalhando em patches e que deve divulgar em breve slides e PoCs (provas de conceito)
• O site está temporariamente reescrito e uma versão melhorada é prometida para o dia seguinte

Significado

• Mostra que existem várias vulnerabilidades ao longo de todo o sistema de assinatura, criptografia e verificação de confiança do GnuPG
• Um exemplo que reforça a necessidade de fortalecer a verificação da confiabilidade básica e a auditoria de código em ferramentas de segurança open source

[GN⁺]

Comentários do Hacker News

• Após a recente divulgação de vulnerabilidades no GnuPG, a confiança ficou abalada. No vídeo da apresentação da CCC, foram revelados zero-days, e houve frustração porque alguns estavam marcados como “wontfix”
  • Houve quem dissesse que “perdeu a confiança em Werner Koch”, e outras pessoas perguntaram o motivo
  • Alguém descreveu o GPG como uma causa perdida (lost cause) já há décadas, dizendo que usuários de segurança mais sérios já migraram para ferramentas alternativas melhores
• Foi publicado um post no blog do GnuPG, mas houve reação de que é difícil aceitar que ainda mantenham um recurso considerado “nocivo” por 30 anos
  • Um usuário lamentou que Werner Koch tenha se dedicado por tanto tempo ao GPG, mas que agora ficaram expostos defeitos estruturais que não podem ser corrigidos pela raiz
• Entre as vulnerabilidades relacionadas ao GPG, algumas envolviam o problema de “texto não confiável contendo ANSI escape codes”, o que, na opinião de alguns, parece uma versão de terminal de XSS
• Também houve análise de que a própria estrutura de pacotes do GPG é excessivamente complexa
  • As mensagens são compostas por vários tipos de pacotes, o que permite que um atacante perturbe a máquina de estados
  • Em especial, o malleability bug causa um problema em que a verificação de autenticação é omitida por causa de erros de transição de estado
  • Argumentou-se que essa complexidade estrutural cria uma “Weird Machine” e que seria preciso redesenhar tudo com um formato binário simples e claro
  • Também houve quem achasse essa explicação excelente
• A discussão também seguiu sobre se o GPG está ou não em conformidade com o padrão
  • Alguns disseram que “isso é um problema só do GnuPG e separado do padrão OpenPGP”, mas outra pessoa apontou que também foram encontradas vulnerabilidades de parser em implementações importantes de PGP (Sequoia, minisign, age etc.)
  • Outro usuário explicou que o campo OpenPGP está dividido entre LiberePGP (GnuPG) e RFC-9580 (Sequoia), cada um adotando abordagens minimalistas e maximalistas, respectivamente. Destacou que é importante evitar guerras de padrão e manter a interoperabilidade
  • Alguns afirmaram que o problema de clearsig é um defeito do próprio padrão OpenPGP
  • Outra pessoa avaliou que os bugs do GPG acabam vindo de problemas estruturais do protocolo PGP, ou seja, na prática seriam bugs no nível do protocolo
• Em relação às assinaturas com GPG, surgiu a pergunta: “ainda é seguro continuar usando GPG para assinar git commit/tags?”
  • Um usuário citou a “vulnerabilidade de bitflip” do GPG como exemplo e explicou que se trata de um problema grave em que um atacante pode manipular o texto em claro
  • Outra pessoa apontou que a própria estrutura de compartilhar uma única chave entre vários aplicativos é arriscada, defendendo que o mais seguro é usar chaves separadas para cada app
  • Em outra opinião, essas vulnerabilidades não chegam ao nível de ataque remoto, e o conselho foi de uso cuidadoso em vez de pânico
  • Um usuário compartilhou a experiência de usar GPG e YubiKey em vários dispositivos e depois migrar para o 1Password SSH agent, o que tornou tudo muito mais simples
  • Outra pessoa enfatizou que, para substituir o GPG de vez, é preciso resolver o problema da distribuição de chaves. Apontou que isso é mais difícil do que a assinatura em si: como distribuir chaves públicas de forma confiável
• Também surgiram preocupações sobre a tendência, no ecossistema Rust, de usar a licença MIT sem muita reflexão
  • Um usuário disse que muitas vezes ela é usada “porque MIT é o padrão”, e alertou que, se a proteção copyleft da GPL3 desaparecer, o controle do usuário pode enfraquecer
  • Outra pessoa concordou e disse que antes usava MIT, mas agora está migrando todos os projetos para copyleft total
  • Outro comentário analisou que esse fenômeno aparece não só em Rust, mas na maioria dos ecossistemas de linguagens modernas
    • Diante da realidade de grandes empresas construindo impérios sobre código voluntário, essa pessoa passou a valorizar novamente o copyleft
    • Mas também disse que, em ambientes onde restrições legais impedem o uso da GPL, não resta alternativa além de escolher licenças permissivas por razões práticas
    • Lamentou que um copyleft fraco como a Mozilla Public License pudesse ter servido como meio-termo, mas que a FSF não a promoveu o suficiente
  • Houve quem defendesse que, “numa era em que não humanos (LLMs) aprendem com código, precisamos de uma nova licença centrada em humanos”
  • Outra pessoa comentou que “seja GPL ou MIT, no fim das contas controle de uso também é uma feature”, olhando para a lógica de controle do software livre por uma perspectiva funcional
  • Um usuário deixou uma observação mais pragmática: “no fim, para o software sobreviver por muito tempo, o primeiro passo é corrigir os bugs”
• Também havia quem ainda considere o GPG útil
  • Com smartcards OpenPGP ou YubiKey, ele continua bastante estável e é mais fácil de configurar do que outras soluções de hardware
  • A pessoa pretende continuar usando-o não para email, mas para backups criptografados, gerenciadores de senhas e gerenciamento de chaves SSH