CVE-2026-71887 in BC-JAVA
Résumé
par VulDB • 03/10/2026
Chez Bouncy Castle pour Java avant la version 1.86, l'API OpenPGP de haut niveau a accepté une signature de données effectuée par une sous-clé de signature dont la signature de liaison de sous-clé ne comportait aucune signature de liaison de clé principale (cross-certification) intégrée, dans le cas où cette liaison omettait un sous-paquet Key Flags. La section 5.2.1.8 et la section 10.1.3 de la RFC 9580 exigent une signature de liaison de clé principale intégrée sur toute sous-clé capable d'émettre des signatures ; il s'agit de l'affirmation propre à la sous-clé indiquant qu'elle appartient à la clé principale sous laquelle elle est liée. OpenPGPCertificate résolvait les Key Flags de la sous-clé selon deux méthodes différentes. isSigningKey() passe par getKeyFlags() et getApplyingSubpacket(), qui recourt en dernier ressort à la signature auto-signée directe ou de l'ID utilisateur principal lorsque la signature de liaison omet le sous-paquet, permettant ainsi à la sous-clé d'hériter des SIGN_DATA du principal et étant considérée comme capable de signer ; verifyEmbeddedPrimaryKeyBinding(), qui applique cette exigence, lit les sous-paquets hachés propres à la signature de liaison, ne trouve aucun SIGN_DATA à cet endroit, et renvoie tôt en tant que clé non signante sans jamais exiger la signature arrière (back signature). La même sous-clé était donc capable de signer – ses signatures étaient ainsi attribuées au certificat et OpenPGPSignature.OpenPGPDocumentSignature.isValid() retournait true – tout en étant exemptée de cross-certification, alors que GnuPG refuse le certificat et le message identiques. Un attaquant n'a besoin que de la sous-clé publique de signature de la victime, qui est une donnée publique : il la lie à sa propre clé principale via une signature de liaison de sous-clé qu'il peut créer, ne comportant ni Key Flags ni signature de liaison de clé principale intégrée (qu'il ne pourrait pas créer sans la clé privée de la sous-clé), et un tiers de confiance vérifiant l'une des messages authentiquement signés par la victime contre ce certificat se voit indiquer que la signature est valide et reçoit le certificat de l'attaquant en tant qu'émetteur. Comme les User IDs d'un certificat sont auto-assertés, un vérificateur qui s'ancre sur l'empreinte ou l'ID de clé de la sous-clé tout en récupérant l'identité du certificat englobant signale une signature réelle émise sous une identité choisie par l'attaquant. Il s'agit d'une mauvaise attribution (misattribution) d'une signature authentique plutôt que d'un forgement d'une nouvelle signature : aucune clé privée n'est récupérée, et la signature doit être celle réellement produite par la sous-clé greffée. L'API de bas niveau PGPSignature / PGPPublicKeyRing ne réalise pas de vérifications de liaison par conception et n'est donc pas affectée. Les Key Flags sont une déclaration concernant la clé à laquelle se réfère la signature porteuse (RFC 9580, section 5.2.3.29), de sorte qu'une sous-clé n'hérite plus des flags provenant des signatures globales au certificat de la clé principale : une signature de liaison de sous-clé qui omet le sous-paquet laisse désormais la sous-clée sans capacités plutôt qu'avec celles du principal, ce qui fait que les flags consultés par la vérification de cross-certification sont identiques à ceux consultés pour toute autre décision. Les préférences et les autres sous-paquets portés par une signature directe-key sont héritées comme auparavant, et la clé principale elle-même, dont les flags proviennent légitimement de sa propre signature auto-signée directe ou d'ID utilisateur, n'est pas affectée.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.