Wysoki Odebrany

CVE-2026-71887

opublikowano: 03.10.2026, 11:17

modyfikacja: 03.10.2026, 11:17

Ocena CVSS

8.2

Wysoki · v4.0

Oficjalne źródła

wektor: CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:Amber

>_ Opis

Tłumaczenie automatyczne – może zawierać nieścisłości.

W Bouncy Castle dla Java przed wersją 1.86 wysokopoziomowy interfejs API OpenPGP akceptował podpis danych wykonany przez podklucz podpisujący, którego sygnatura wiązania podklucza nie zawierała wbudowanego podpisu wiązania klucza podstawowego (certyfikacji krzyżowej), w przypadku, gdy to powiązanie pomija podpakiet Key Flags. RFC 9580 sek. 5.2.1.8 i ust. 10.1.3 wymagać osadzonego podpisu wiązania klucza podstawowego w każdym podkluczu, który może wystawiać podpisy; jest to własne oświadczenie podklucza, że należy on do klucza podstawowego, z którym jest powiązany. OpenPGPCertificate rozwiązał flagi kluczy podklucza na dwa różne sposoby. Funkcja isSigningKey() przechodzi przez getKeyFlags() i getApplyingSubpacket(), która powraca do klucza bezpośredniego klucza podstawowego lub podpisu własnego podstawowego identyfikatora użytkownika, gdy podpis wiążący pomija podpakiet, więc podklucz odziedziczył SIGN_DATA klucza podstawowego i jest liczony jako zdolny do podpisywania; VerifyEmbeddedPrimaryKeyBinding(), która wymusza to wymaganie, odczytuje własne zaszyfrowane podpakiety sygnatury wiązania, nie znajduje tam żadnych SIGN_DATA i zwraca wcześniej jako klucz niepodpisujący, nigdy nie żądając podpisu zwrotnego. Ten sam podklucz mógł zatem podpisywać - więc jego podpisy zostały przypisane do certyfikatu, a OpenPGPSignature.OpenPGPDocumentSignature.isValid() zwróciło wartość true - będąc jednocześnie zwolnionym z certyfikacji krzyżowej, gdzie GnuPG odrzuca identyczny certyfikat i komunikat. Osoba atakująca potrzebuje jedynie publicznego podklucza podpisu ofiary, który jest materiałem publicznym: wiąże go z własnym kluczem podstawowym za pomocą podpisu Subkey Binding, który jest w stanie wykonać, nie niosąc flag kluczowych ani wbudowanego podpisu Primary Key Binding, którego nie może wykonać bez prywatnego klucza podklucza, a strona ufająca weryfikująca jedną z rzeczywiście podpisanych wiadomości ofiary na podstawie tego certyfikatu zostaje poinformowana, że podpis jest ważny i otrzymuje certyfikat atakującego jako jego wystawcy. Ponieważ identyfikatory użytkowników certyfikatów są potwierdzane samodzielnie, weryfikator, który przypina odcisk palca podklucza lub identyfikator klucza podczas pobierania tożsamości z dołączonego certyfikatu, zgłasza prawdziwy podpis pod tożsamością wybraną przez atakującego. Jest to raczej błędne przypisanie prawdziwego podpisu niż sfałszowanie nowego: żaden klucz prywatny nie jest odzyskiwany, a podpis musi należeć do faktycznie wykonanego przeszczepionego podklucza. Niskopoziomowy interfejs API PGPSignature / PGPPublicKeyRing nie przeprowadza żadnych kontroli powiązań z założenia i nie ma na to wpływu. Flagi kluczy to instrukcja dotycząca klucza, do którego odnosi się podpis nośny (RFC 9580, rozdz. 5.2.3.29), więc podklucz nie dziedziczy ich już z podpisów klucza podstawowego obejmujących cały certyfikat: podpis podklucza wiązania, który pomija podpakiet, pozostawia teraz podklucz bez możliwości, a nie klucz podstawowy, co sprawia, że flagi podczas kontroli krzyżowej certyfikacji sprawdzają te same flagi, z którymi konsultowana jest każda inna decyzja. Preferencje i inne podpakiety niesione przez podpis klucza bezpośredniego są dziedziczone jak poprzednio, a sam klucz podstawowy, którego flagi zgodnie z prawem pochodzą z jego własnego klucza bezpośredniego lub podpisu własnego identyfikatora użytkownika, pozostaje niezmieniony.

In Bouncy Castle for Java before 1.86, the high-level OpenPGP API accepted a data signature made by a signing subkey whose Subkey Binding signature carried no embedded Primary Key Binding (cross-certification) signature, in the case where that binding omits a Key Flags subpacket. RFC 9580 sec. 5.2.1.8 and sec. 10.1.3 require the embedded Primary Key Binding signature on any subkey that can issue signatures; it is the subkey's own statement that it belongs to the primary key it is bound under. OpenPGPCertificate resolved the subkey's key flags two different ways. isSigningKey() goes through getKeyFlags() and getApplyingSubpacket(), which falls back to the primary key's direct-key or primary User ID self-signature when the binding signature omits the subpacket, so the subkey inherited the primary's SIGN_DATA and counted as signing-capable; verifyEmbeddedPrimaryKeyBinding(), which enforces the requirement, reads the binding signature's own hashed subpackets, found no SIGN_DATA there, and returned early as a non-signing key without ever demanding the back signature. The same subkey was therefore signing-capable - so its signatures were attributed to the certificate and OpenPGPSignature.OpenPGPDocumentSignature.isValid() returned true - while being exempt from cross-certification, where GnuPG refuses the identical certificate and message. An attacker needs only the victim's public signing subkey, which is public material: they bind it to their own primary key with a Subkey Binding signature they are able to make, carrying no Key Flags and no embedded Primary Key Binding signature, which they cannot make without the subkey's private key, and a relying party verifying one of the victim's genuinely signed messages against that certificate is told the signature is valid and given the attacker's certificate as its issuer. Because a certificate's User IDs are self-asserted, a verifier that pins on the subkey's fingerprint or key ID while taking the identity from the enclosing certificate reports a real signature under an attacker-chosen identity. This is misattribution of a genuine signature rather than forgery of a new one: no private key is recovered, and the signature must be one the grafted subkey actually made. The low-level PGPSignature / PGPPublicKeyRing API performs no binding checks by design and is unaffected. Key Flags are a statement about the key the carrying signature refers to (RFC 9580 sec. 5.2.3.29), so a subkey no longer inherits them from the certificate-wide signatures of the primary key: a Subkey Binding signature that omits the subpacket now leaves the subkey with no capabilities rather than the primary's, which makes the flags the cross-certification check consults the same flags every other decision consults. Preferences and the other subpackets a direct-key signature carries are inherited as before, and the primary key itself, whose flags legitimately come from its own direct-key or User ID self-signature, is unaffected.

>_ Słabości (CWE)

CWE-345 CWE-347

>_ Referencje

Dane podatności pochodzą z oficjalnych źródeł (CVE® List / NVD). Opisy po polsku są tłumaczone automatycznie i mogą zawierać nieścisłości – na stronie rekordu można wyświetlić wersję angielską.

This product uses the NVD API but is not endorsed or certified by the NVD.

CVE Usage: MITRE hereby grants you a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute Common Vulnerabilities and Exposures (CVE®). Any copy you make for such purposes is authorized provided that you reproduce MITRE's copyright designation and this license in any such copy. ALL DOCUMENTS AND THE INFORMATION CONTAINED THEREIN PROVIDED BY MITRE ARE PROVIDED ON AN "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND.

NVD Terms of Use / CVE® Terms of Use / nvd.nist.gov / cve.org

<< baza_cve