CVE-2026-71887 in BC-JAVA
Riassunto
di VulDB • 03/10/2026
In Bouncy Castle per Java prima della versione 1.86, l'API OpenPGP di alto livello accettava una firma dei dati creata da un sottochiave (subkey) di firma la cui firma di associazione del sottochiave non conteneva alcuna firma di binding della chiave primaria (cross-certification), nel caso in cui tale binding omettesse il subpacket Key Flags. La sezione 5.2.1.8 e la sezione 10.1.3 di RFC 9580 richiedono l'inserimento della firma di binding della chiave primaria su qualsiasi sottochiave abilitata a emettere firme; essa rappresenta l'affermazione diretta del sottochiave che appartiene alla chiave primaria sotto cui è vincolato. OpenPGPCertificate risolveva le flag (Key Flags) del sottochiave in due modi diversi. Il metodo isSigningKey() passa attraverso getKeyFlags() e getApplyingSubpacket(), che fa fallback sulla firma di auto-verifica diretta della chiave primaria o dell'User ID primario quando la firma di binding omette il subpacket, consentendo così al sottochiave di ereditare le flag SIGN_DATA dalla chiave primaria ed essere considerato abilitato alla firma; verifyEmbeddedPrimaryKeyBinding(), che applica tale requisito, legge i subpacket hashati della propria firma di binding, non trovava SIGN_DATA e restituiva precocemente il sottochiave come non abilitato alla firma senza mai richiedere la retro-firma (back signature). Di conseguenza, lo stesso sottochiave risultava abilitato alla firma: le sue firme venivano quindi attribuite al certificato e OpenPGPSignature.OpenPGPDocumentSignature.isValid() restituiva true, pur essendo esente dalla cross-certification, mentre GnuPG rifiuta il certificato e il messaggio identici. Un attaccante necessita solo della sottochiave pubblica di firma della vittima, che è materiale pubblico: la lega alla propria chiave primaria con una firma di associazione del sottochiave (Subkey Binding signature) che l'attaccante può generare, priva di Key Flags e senza la firma embedded di binding della chiave primaria (che non potrebbe creare senza la chiave privata del sottochiave), e un party affidatario (relying party) che verifica una messaggio genuinamente firmato dalla vittima contro tale certificato riceve l'affermazione che la firma è valida e vede il certificato dell'attaccante come emittente. Poiché gli User ID di un certificato sono auto-asseriti, un verificatore che fissa (pins) l'impronta digitale o l'ID della chiave del sottochiave mentre assume l'identità dal certificato contenitore segnala una firma reale sotto un'identità scelta dall'attaccante. Si tratta di una misattribuzione di una firma genuina piuttosto che di una falsificazione di una nuova: non viene recuperata alcuna chiave privata e la firma deve essere necessariamente quella effettivamente creata dal sottochiave innestato (grafted). L'API a basso livello PGPSignature / PGPPublicKeyRing, per progettazione, non esegue controlli di binding ed è quindi non interessata. Le Key Flags sono un'affermazione riguardante la chiave alla quale si riferisce la firma portatrice (RFC 9580 sec. 5.2.3.29), pertanto un sottochiave non eredita più le flag dalle firme a livello di certificato della chiave primaria: una firma di associazione del sottochiave che omette il subpacket lascia ora il sottochiave senza capacità operative piuttosto che con quelle della chiave primaria, rendendo così le flag consultate dal controllo di cross-certification coerenti con quelle utilizzate da ogni altra decisione. Le preferenze e gli altri subpacket contenuti in una firma diretta-key vengono ereditati come in precedenza, mentre la chiave primaria stessa, le cui flag derivano legittimamente dalla propria firma di auto-verifica diretta-key o dell'User ID, rimane non interessata.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.