Gpg.fail

 (gpg.fail)
4 points par GN⁺ 2025-12-28 | 1 commentaires | Partager sur WhatsApp
  • Un site web qui divulgue plusieurs vulnérabilités de sécurité liées à GnuPG, avec des liens vers une page détaillée pour chacune
  • Le site répertorie divers cas problématiques survenant lors des processus de signature PGP, chiffrement et vérification de confiance
  • Parmi les principaux éléments figurent des attaques en texte clair, la traversée de chemin, des erreurs de calcul de hachage, la corruption mémoire et des signatures falsifiées
  • L’auteur indique être en train de réécrire le site dans l’urgence et prévoit de publier bientôt des slides, des PoC et des patchs
  • Un cas qui met en évidence la nécessité de vérifier sérieusement l’intégrité des signatures et le modèle de confiance des outils de sécurité open source

Aperçu du site

  • gpg.fail est un site qui rassemble et publie des vulnérabilités de GnuPG (implémentation d’OpenPGP)
    • Chaque entrée renvoie, via un lien distinct, vers une page d’analyse technique détaillée
    • L’auteur précise qu’il a laissé le code source du site chez lui et qu’il est en train de le réécrire, en ajoutant : « attendez-vous à une meilleure version demain »
  • En haut du site, la mention "Slides, pocs and patches soon!" annonce la publication prochaine de documents complémentaires

Principales vulnérabilités rendues publiques

  • Multiple Plaintext Attack on Detached PGP Signatures
    • Indique qu’une attaque multi-texte clair est possible sur les signatures PGP détachées
  • GnuPG Accepts Path Separators and Path Traversals in Literal Data "Filename" Field
    • GnuPG accepte des séparateurs de chemin et la traversée de répertoires dans le champ de nom de fichier des données littérales
  • Cleartext Signature Plaintext Truncated for Hash Calculation
    • Problème où le texte clair est tronqué lors du calcul du hachage
  • Encrypted message malleability checks are incorrectly enforced causing plaintext recovery attacks
    • Les vérifications de malléabilité du message chiffré sont appliquées de manière incorrecte, permettant des attaques de récupération du texte clair
  • Memory Corruption in ASCII-Armor Parsing
    • Possibilité de corruption mémoire pendant le parsing de l’ASCII-Armor
  • Trusted comment injection (minisign)
    • Possibilité d’injection de commentaire de confiance (trusted comment) dans minisign
  • Cleartext Signature Forgery in the NotDashEscaped header implementation in GnuPG
    • Possibilité de falsification de signature en texte clair dans l’implémentation de l’en-tête NotDashEscaped
  • OpenPGP Cleartext Signature Framework Susceptible to Format Confusion
    • Vulnérable à une confusion de format au niveau du framework de signature en texte clair d’OpenPGP
  • GnuPG Output Fails To Distinguish Signature Verification Success From Message Content
    • La sortie ne distingue pas correctement le succès de la vérification de signature du contenu du message
  • Cleartext Signature Forgery in GnuPG
    • Possibilité de falsification de signature en texte clair en raison d’une erreur de traitement des octets NULL
  • Radix64 Line-Truncation Enabling Polyglot Attacks
    • La troncature de lignes en Radix64 permet des attaques polyglottes
  • GnuPG may downgrade digest algorithm to SHA1 during key signature checking
    • Lors de la vérification de signatures de clés, GnuPG peut rétrograder l’algorithme de hachage vers SHA1
  • GnuPG Trust Packet Parsing Enables Adding Arbitrary Subkeys
    • Le parsing des paquets de confiance permet d’ajouter des sous-clés arbitraires
  • Trusted comment Injection (minisign)
    • La vulnérabilité d’injection de commentaire de confiance liée à minisign est mentionnée une seconde fois

Plan de publication

  • L’auteur est actuellement en train de préparer des patchs et prévoit de publier prochainement des slides et des PoC (proofs of concept)
  • Le site a été réécrit de manière temporaire, avec l’annonce d’une version améliorée le lendemain

Portée

  • Cela montre l’existence de nombreuses vulnérabilités touchant l’ensemble du système de signature, de chiffrement et de vérification de confiance de GnuPG
  • Un exemple qui souligne la nécessité de renforcer la vérification de la fiabilité fondamentale et les audits de code des outils de sécurité open source

À lire aussi

1 commentaires

 
GN⁺ 2025-12-28
Réactions sur Hacker News
  • Depuis la récente divulgation de vulnérabilités dans GnuPG, la confiance est ébranlée. Des zero-days ont été révélés dans la présentation du CCC, et le fait que certains soient marqués « wontfix » a suscité de la déception
    • Quelqu’un a dit avoir « perdu confiance en Werner Koch », et d’autres ont demandé pourquoi
    • Certains ont décrit GPG comme une cause perdue depuis déjà des décennies, affirmant que les utilisateurs sérieux en sécurité sont déjà passés à de meilleurs outils alternatifs
  • Un billet de blog de GnuPG a été publié, mais certains ont jugé difficilement défendable le maintien d’une fonctionnalité considérée comme « nuisible » depuis 30 ans
    • Un utilisateur a regretté que, malgré le long engagement de Werner Koch envers GPG, des défauts structurels impossibles à corriger en profondeur semblent désormais apparaître au grand jour
  • Parmi les vulnérabilités liées à GPG, certaines concernent le problème du « texte non fiable contenant des codes d’échappement ANSI », que certains comparent à une sorte de XSS côté terminal
  • Certains ont aussi analysé la structure en paquets de GPG comme étant excessivement complexe
    • Un message étant composé de plusieurs types de paquets, un attaquant peut perturber la machine à états
    • En particulier, un bug de malléabilité peut provoquer l’absence de vérification de l’authentification à cause d’erreurs de transition d’état
    • Cette complexité structurelle créerait une « Weird Machine », et certains soutiennent qu’il faudrait repartir d’un format binaire simple et clair
    • D’autres ont salué la qualité de cette explication
  • La conformité de GPG au standard a également été discutée
    • Certains ont affirmé que « c’est un problème propre à GnuPG, distinct du standard OpenPGP », mais d’autres ont fait remarquer que des vulnérabilités de parseur ont aussi été trouvées dans d’autres implémentations PGP majeures (Sequoia, minisign, age, etc.)
    • Un autre utilisateur a expliqué que le camp OpenPGP est divisé entre LiberePGP (GnuPG) et RFC-9580 (Sequoia), chacun adoptant respectivement une approche minimaliste et maximaliste. Il a insisté sur l’importance d’éviter une guerre des standards et de préserver l’interopérabilité
    • Certains ont soutenu que le problème de clearsig est un défaut du standard OpenPGP lui-même
    • D’autres ont estimé que les bugs de GPG proviennent au fond de problèmes structurels du protocole PGP, et qu’il s’agit en pratique de bugs au niveau du protocole
  • À propos des signatures GPG, la question a été posée de savoir s’il est encore sûr d’utiliser GPG pour signer des git commit / tag
    • Un utilisateur a pris comme exemple la « vulnérabilité bitflip » de GPG, en expliquant qu’il s’agit d’un problème grave permettant à un attaquant de manipuler le texte en clair
    • Un autre a souligné que le partage d’une même clé entre plusieurs applications est dangereux en soi, et a plaidé pour des clés distinctes pour chaque application
    • Un autre avis a rappelé que ces vulnérabilités ne relèvent pas d’attaques à distance, et qu’il faut donc faire preuve de prudence sans paniquer
    • Un utilisateur a raconté qu’après avoir utilisé GPG et YubiKey sur plusieurs appareils, il est passé à 1Password SSH agent, avec une configuration devenue bien plus simple
    • Quelqu’un d’autre a insisté sur le fait que, pour remplacer totalement GPG, il faut résoudre le problème de la distribution des clés. Plus que la signature elle-même, c’est la manière de distribuer de façon fiable les clés publiques qui est difficile
  • Des inquiétudes ont aussi été exprimées sur la tendance de l’écosystème Rust à adopter machinalement la licence MIT
    • Un utilisateur a dit que beaucoup l’utilisent « parce que c’est la valeur par défaut », avertissant que la disparition de la protection copyleft de la GPL3 peut affaiblir le contrôle des utilisateurs
    • Quelqu’un qui partageait ce point de vue a indiqué qu’il utilisait autrefois MIT, mais qu’il est désormais en train de faire passer tous ses projets en copyleft intégral
    • Un autre a estimé que ce phénomène ne concerne pas seulement Rust, mais la plupart des écosystèmes de langages modernes
      • Face à la réalité de grandes entreprises bâtissant des empires sur du code bénévole, il dit avoir redécouvert la valeur du copyleft
      • Mais dans les environnements où des contraintes juridiques empêchent l’usage de la GPL, il estime qu’on finit par choisir une licence permissive pour des raisons pragmatiques
      • Un copyleft faible comme la Mozilla Public License aurait pu constituer un compromis, mais il regrette que la FSF ne l’ait pas davantage soutenu
    • Certains ont affirmé qu’à l’ère où des entités non humaines (LLM) apprennent à partir du code, il faut de nouvelles licences pensées pour les humains
    • Un autre a soutenu que « qu’il s’agisse de GPL ou de MIT, le contrôle de l’usage est lui aussi une fonctionnalité », abordant ainsi la logique du logiciel libre sous un angle fonctionnel
    • Un utilisateur a laissé un commentaire plus terre-à-terre : au final, pour qu’un logiciel survive longtemps, il faut d’abord corriger les bugs
  • Certaines personnes continuent malgré tout à trouver GPG utile
    • Avec une smart card OpenPGP ou une YubiKey, l’outil reste assez stable et plus facile à configurer que d’autres solutions matérielles
    • Elles comptent continuer à l’utiliser non pas pour le courrier électronique, mais pour les sauvegardes chiffrées, les gestionnaires de mots de passe et la gestion des clés SSH