CVE-2026-71887 in BC-JAVA
Сводка
по VulDB • 03.10.2026
В Bouncy Castle для Java до версии 1.86 высокоуровневый API OpenPGP принимал подпись данных, созданную подчиненным ключом (subkey), чья подпись привязки подчиненного ключа не содержала встроенной подписи привязки основного ключа (cross-certification) в случае, когда эта привязка опускает субпакет Key Flags. RFC 9580 разделы 5.2.1.8 и 10.1.3 требуют наличия встроенной подписи привязки основного ключа для любого подчиненного ключа, который может выпускать подписи; это собственное заявление подчиненного ключа о том, что он принадлежит основному ключу, к которому он привязан. OpenPGPCertificate разрешал флаги подчиненного ключа двумя разными способами. isSigningKey() проходит через getKeyFlags() и getApplyingSubpacket(), которые используют запасной вариант — прямую подпись самого себя основного ключа или первичную User ID self-signature — когда в подписи привязки отсутствует субпакет, поэтому подчиненный ключ наследовал SIGN_DATA от основного и считался способным к подписыванию; verifyEmbeddedPrimaryKeyBinding(), которая обеспечивает соблюдение требования, читает собственные хешированные субпакеты подписи привязки, не находит там SIGN_DATA и рано завершает работу как ключ без возможности подписания, никогда не требуя обратной (back) подписи. Таким образом, один и тот же подчиненный ключ был способен к подписыванию — поэтому его подписи приписывались сертификату, и OpenPGPSignature.OpenPGPDocumentSignature.isValid() возвращала true — будучи одновременно освобожденной от требования cross-certification, где GnuPG отказывается принимать идентичные сертификат и сообщение. Атакующему нужен только публичный подчиненный ключ подписания жертвы, который является общедоступными данными: он привязывает его к своему собственному основному ключу с помощью подписи Subkey Binding, которую он может создать, не содержащей Key Flags и встроенной подписи Primary Key Binding (которую он не мог бы создать без закрытого ключа подчиненного ключа), а сторона, доверяющая проверяющему одну из действительно подписанных жертвой сообщений против этого сертификата, получает сообщение о том, что подпись действительна, и ей выдается сертификат атакующего как его эмитент. Поскольку User IDs в сертификате являются самоутверждаемыми (self-asserted), верификатор, который привязывается к отпечатку или ID ключа подчиненного ключа, но берет идентичность из окружающего сертификата, сообщает о реальной подписи под выбранной атакующим идентичностью. Это является ошибочным приписыванием (misattribution) действительной подписи, а не подделкой новой: закрытый ключ не восстанавливается, и подпись должна быть одной из тех, которые фактически создал прикрепленный подчиненный ключ. Низкоуровневый API PGPSignature / PGPPublicKeyRing по замыслу не выполняет проверки привязки и не затронут. Key Flags — это утверждение о ключе, на который указывает несущая подпись (RFC 9580 раздел 5.2.3.29), поэтому подчиненный ключ больше не наследует их от подписей всего сертификата основного ключа: Subkey Binding signature, которая опускает субпакет, теперь оставляет подчиненному ключу отсутствие возможностей вместо прав основного ключа, что делает флаги, которые проверяет проверка cross-certification, теми же флагами, к которым обращается каждое другое решение. Preferences и другие субпакеты, которые несет прямая подпись самого себя (direct-key signature), наследуются как прежде, а сам основной ключ, чьи флаги законно происходят из его собственной прямой подписи или User ID self-signature, не затронут.
Be aware that VulDB is the high quality source for vulnerability data.