Gpg.fail

• Un sitio web que divulgó múltiples vulnerabilidades de seguridad relacionadas con GnuPG, enlazando páginas con explicaciones detalladas de cada una
• El sitio enumera varios casos problemáticos que ocurren durante los procesos de firma PGP, cifrado y verificación de confianza
• Entre los puntos principales se incluyen ataques de texto plano, path traversal, errores en el cálculo de hash, corrupción de memoria y firmas falsificadas
• El responsable menciona que está reescribiendo apresuradamente el sitio y que pronto publicará diapositivas, PoC y parches
• Un caso que revela la seria necesidad de verificar la integridad de las firmas y el modelo de confianza en herramientas de seguridad de código abierto

---

Descripción general del sitio

• gpg.fail está organizado como un sitio que recopila y publica vulnerabilidades de GnuPG (implementación de OpenPGP)
  • Cada elemento enlaza a una página aparte con análisis técnicos detallados
  • El responsable comentó: “Dejé el código fuente del sitio en casa, así que lo estoy reescribiendo; esperen una mejor versión mañana”
• En la parte superior del sitio aparece la frase “Slides, pocs and patches soon!”, anticipando la futura publicación de materiales

Lista de principales vulnerabilidades publicadas

• Multiple Plaintext Attack on Detached PGP Signatures
  • Señala que es posible realizar un ataque de texto plano múltiple sobre firmas PGP separadas
• GnuPG Accepts Path Separators and Path Traversals in Literal Data "Filename" Field
  • GnuPG permite separadores de ruta y path traversal en el campo de nombre de archivo de los datos literales
• Cleartext Signature Plaintext Truncated for Hash Calculation
  • Ocurre un problema en el que el texto plano se trunca durante el cálculo del hash
• Encrypted message malleability checks are incorrectly enforced causing plaintext recovery attacks
  • Las verificaciones de maleabilidad del mensaje cifrado se aplican incorrectamente, permitiendo ataques de recuperación de texto plano
• Memory Corruption in ASCII-Armor Parsing
  • Puede ocurrir corrupción de memoria durante el parsing de ASCII-Armor
• Trusted comment injection (minisign)
  • Posibilidad de inyección de comentarios confiables (trusted comment) en minisign
• Cleartext Signature Forgery in the NotDashEscaped header implementation in GnuPG
  • Posibilidad de falsificación de firmas de texto claro en la implementación del encabezado NotDashEscaped
• OpenPGP Cleartext Signature Framework Susceptible to Format Confusion
  • Vulnerable a confusión de formato (format confusion)
• GnuPG Output Fails To Distinguish Signature Verification Success From Message Content
  • Un problema de salida en el que no se distingue entre el éxito de la verificación de la firma y el contenido del mensaje
• Cleartext Signature Forgery in GnuPG
  • Posibilidad de falsificación de firmas de texto claro debido a un error en el manejo de bytes NULL
• Radix64 Line-Truncation Enabling Polyglot Attacks
  • El truncamiento de líneas en Radix64 permite ataques polyglot
• GnuPG may downgrade digest algorithm to SHA1 during key signature checking
  • El algoritmo de hash puede degradarse a SHA1 durante la verificación de firmas de claves
• GnuPG Trust Packet Parsing Enables Adding Arbitrary Subkeys
  • Posibilidad de agregar subclaves arbitrarias durante el parsing de paquetes de confianza
• Trusted comment Injection (minisign)
  • Se menciona nuevamente una vulnerabilidad de inyección de comentarios confiables relacionada con minisign

Próximos pasos

• El responsable está actualmente trabajando en parches y planea publicar pronto diapositivas y PoC (pruebas de concepto)
• El sitio se encuentra temporalmente reescrito y anticipa una versión mejorada al día siguiente

Significado

• Muestra que existen numerosas vulnerabilidades en todo el sistema de firma, cifrado y verificación de confianza de GnuPG
• Un caso que subraya la necesidad de reforzar la verificación de confiabilidad básica y las auditorías de código en herramientas de seguridad de código abierto

[GN⁺]

Comentarios en Hacker News

• Tras la reciente divulgación de vulnerabilidades en GnuPG, la confianza se ha visto sacudida. En la charla del CCC se revelaron zero-days, y decepcionó que algunos aparecieran marcados como “wontfix”
  • Hubo quien dijo que “se perdió la confianza en Werner Koch”, y otros preguntaron por qué
  • Alguien describió a GPG como una causa perdida (lost cause) desde hace décadas, diciendo que los usuarios serios de seguridad ya migraron a herramientas alternativas mejores
• Se publicó una entrada en el blog de GnuPG, pero hubo reacciones diciendo que cuesta entender por qué siguen manteniendo una función considerada “dañina” durante 30 años
  • Un usuario lamentó que, aunque Werner Koch dedicó mucho tiempo a GPG, ahora quedaron expuestos defectos estructurales que no se pueden corregir de raíz
• Entre las vulnerabilidades relacionadas con GPG, algunas trataban del problema de “texto no confiable que incluye códigos de escape ANSI”, lo que para algunos se siente como una versión para terminal de XSS
• También hubo análisis de que la propia estructura de paquetes de GPG es excesivamente compleja
  • Los mensajes están compuestos por paquetes de varios tipos, lo que permite a un atacante desestabilizar la máquina de estados
  • En particular, un malleability bug provoca que se omita la verificación de autenticación por errores en las transiciones de estado
  • Se argumentó que esta complejidad estructural crea una “Weird Machine” y que debería rediseñarse con un formato binario simple y claro
  • También hubo quien dijo que esa explicación era excelente
• Continuó además la discusión sobre si GPG cumple o no con el estándar
  • Algunos dijeron que “esto es un problema exclusivo de GnuPG y aparte del estándar OpenPGP”, pero otros señalaron que también se encontraron vulnerabilidades de parser en implementaciones principales de PGP como Sequoia, minisign y age
  • Otro usuario explicó que el ecosistema OpenPGP está dividido entre LiberePGP (GnuPG) y RFC-9580 (Sequoia), y que cada uno adopta un enfoque minimalista o maximalista. Remarcó que es importante evitar guerras de estándares y mantener la interoperabilidad
  • Algunos sostuvieron que el problema de clearsig es un defecto del propio estándar OpenPGP
  • Otro comentó que los bugs de GPG en última instancia provienen de problemas estructurales del protocolo PGP, y los evaluó como fallas a nivel de protocolo
• Sobre las firmas de GPG, apareció la pregunta de si “¿sigue siendo seguro usar GPG para firmar git commit/tag?”
  • Un usuario puso como ejemplo la “vulnerabilidad bitflip” de GPG, explicando que es un problema grave que permite a un atacante manipular texto plano
  • Otra persona señaló que la propia estructura de compartir una sola clave entre varias aplicaciones es riesgosa, y sostuvo que es más seguro tener claves separadas para cada app
  • Otra opinión fue que estas vulnerabilidades no están al nivel de un ataque remoto, por lo que recomendó uso cuidadoso en lugar de pánico
  • Un usuario compartió que, tras usar GPG y YubiKey en varios dispositivos, cambió a 1Password SSH agent y todo se volvió mucho más simple
  • Otro recalcó que para reemplazar GPG por completo hay que resolver el problema de distribución de claves. Señaló que, más que la firma en sí, lo difícil es distribuir claves públicas de forma confiable
• También surgieron preocupaciones sobre la tendencia dentro del ecosistema Rust a usar la licencia MIT sin pensarlo mucho
  • Un usuario dijo que muchas veces se usa “porque MIT es el valor por defecto”, y advirtió que si desaparece la protección copyleft de GPL3, el control del usuario puede debilitarse
  • Alguien que estuvo de acuerdo comentó que antes usaba MIT, pero ahora está cambiando todos sus proyectos a copyleft completo
  • Otra persona analizó que este fenómeno no aparece solo en Rust, sino en la mayoría de los ecosistemas de lenguajes modernos
    • La realidad de que las grandes empresas construyen imperios sobre código voluntario lo hizo volver a valorar el copyleft
    • Pero también dijo que, en entornos donde no se puede usar GPL por restricciones legales, no queda otra que elegir licencias permisivas por razones prácticas
    • Comentó con pesar que un copyleft débil como la Mozilla Public License podría haber sido un punto intermedio, pero que la FSF no la impulsó lo suficiente
  • Alguien sostuvo que “en una era donde no humanos (LLM) aprenden del código, se necesita una nueva licencia centrada en los humanos”
  • Otra persona dijo que “sea GPL o MIT, al final el control de uso también es una feature”, viendo la lógica de control del software libre desde una perspectiva funcional
  • Un usuario dejó una opinión pragmática: “si el software quiere sobrevivir mucho tiempo, lo primero es corregir los bugs”
• También hubo personas que todavía consideran útil a GPG
  • Con smartcards OpenPGP o junto con YubiKey resulta bastante estable, y la configuración es más sencilla que con otras soluciones de hardware
  • Planean seguir usándolo no tanto para correo electrónico, sino para backups cifrados, gestores de contraseñas y manejo de claves SSH