Improper Validation of Integrity Check ValueAffected versions of this package are vulnerable to Improper Validation of Integrity Check Value in the org.bouncycastle.openpgp.api streaming decryption path and the AEAD decryption streams. An attacker can cause decrypted plaintext to be accepted without an error, or have following packets silently dropped, by supplying a message truncated at an AEAD chunk boundary or a truncated SEIPDv1 message that reaches the high-level OpenPGP API. In the AEAD path, BcAEADUtil and JceAEADUtil read an EOFException as a clean end of message through BCPGInputStream.nextPacketTag(), so the caller receives authenticated chunk plaintext with no truncation failure reported. In the SEIPDv1 path, OpenPGPMessageInputStream.close() does not ensure the integrity-protected stream is closed, so the MDC verification in IntegrityProtectedInputStream never runs and the recipient gets CFB-decrypted plaintext with no integrity check.
How to fix Improper Validation of Integrity Check Value? Upgrade org.bouncycastle:bcpg-fips to version 1.0.14, 2.0.14.1, 2.1.14 or higher.
| [1.0.7,1.0.14)[2.0.7,2.0.14.1)[2.1.0,2.1.14) |
Allocation of Resources Without Limits or ThrottlingAffected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling in the S2K.Argon2Params class and the PGPUtil.makeKeyFromPassPhrase() method, which read the one-byte OpenPGP Argon2 passes, parallelism, and memory-size exponent fields with only a default cap of memorySizeExponent <= 30 (1 TiB) and feed them straight into Argon2BytesGenerator. An attacker can exhaust memory or stall the process with up to roughly 1 TiB of allocation and heavy CPU work before any authenticity check, by embedding these Argon2 parameters in a minimal SKESK or secret-key packet that the victim attempts to decrypt with a passphrase. This requires the victim to begin passphrase-based decryption of the attacker-supplied message or key, since the cost is incurred during S2K key derivation ahead of authentication.
How to fix Allocation of Resources Without Limits or Throttling? A fix was pushed into the master branch but not yet published.
| |
