CVE-2026-71887 in BC-JAVA
Resumen
por VulDB • 2026-10-03
En Bouncy Castle para Java anterior a la versión 1.86, la API de alto nivel OpenPGP aceptaba una firma de datos realizada por una subclave de firma cuya firma de enlace de subclave no incluía ninguna firma incrustada de Enlace de Clave Principal (cross-certification), en el caso en que dicho enlace omitiera un subpaquete de Banderas de Clave. El RFC 9580, secciones 5.2.1.8 y 10.1.3, exige la firma incrustada de Enlace de Clave Principal en cualquier subclave capaz de emitir firmas; es la propia declaración del subclave que indica que pertenece a la clave principal bajo la cual está vinculada. OpenPGPCertificate resolvía las banderas de clave del subclave de dos maneras diferentes. isSigningKey() pasa por getKeyFlags() y getApplyingSubpacket(), lo que recurre a la firma directa o la auto-firma de User ID primaria cuando la firma de enlace omite el subpaquete, por lo que el subclave heredaba SIGN_DATA y se consideraba capaz de firmar; verifyEmbeddedPrimaryKeyBinding(), que aplica el requisito, lee los subpaquetes hash propios de la firma de enlace, no encuentra SIGN_DATA allí y devuelve temprano como una clave sin capacidad de firma sin exigir nunca la firma posterior. Por tanto, el mismo subclave era capaz de firmar (por lo que sus firmas se atribuían al certificado y OpenPGPSignature.OpenPGPDocumentSignature.isValid() devolvía true) mientras estaba exento de cross-certification, donde GnuPG rechaza el certificado y mensaje idénticos. Un atacante solo necesita la subclave pública de firma de la víctima, que es material público: lo vincula a su propia clave principal con una Firma de Enlace de Subclave que puede crear, sin Banderas de Clave ni firma incrustada de Enlace de Clave Principal (que no podría crear sin la clave privada del subclave), y un partido confiado que verifica uno de los mensajes genuinamente firmados por la víctima contra ese certificado se le dice que la firma es válida y se le proporciona el certificado del atacante como su emisor. Dado que las User IDs de un certificado son auto-afirmadas, un verificador que ancla en la huella digital o ID de clave del subclave mientras toma la identidad del certificado circundante informa una firma real bajo una identidad elegida por el atacante. Esto es una mala atribución de una firma genuina más que una falsificación de una nueva: no se recupera ninguna clave privada, y la firma debe ser una que el subclave injertado realmente haya realizado. La API de nivel inferior PGPSignature / PGPPublicKeyRing no realiza comprobaciones de enlace por diseño y no se ve afectada. Las Banderas de Clave son una declaración sobre la clave a la que se refiere la firma portadora (RFC 9580 sec. 5.2.3.29), por lo que un subclave ya no las hereda de las firmas generales del certificado de la clave principal: una Firma de Enlace de Subclave que omite el subpaquete ahora deja al subclave sin capacidades en lugar de con las de la clave principal, lo que hace que las banderas consultadas por la comprobación de cross-certification sean las mismas banderas que consulta cualquier otra decisión. Las Preferencias y los otros subpaquetes que lleva una firma directa-key se heredan como antes, y la propia clave principal, cuyas banderas provienen legítimamente de su propia firma directa-key o auto-firma de User ID, no se ve afectada.
Once again VulDB remains the best source for vulnerability data.