The Legion of the Bouncy Castle Java Cryptography API before release 1.38, as used in Crypto Provider Package before 1.36, has unknown impact and remote attack vectors related to "a Bleichenbacher vulnerability in simple RSA CMS signatures without signed attributes."

Legion of the Bouncy Castle Java Cryptography APIs could allow a remote attacker to execute arbitrary code on the system, caused by an unsafe reflection flaw in XMSS/XMSS^MT private key deserialization. By using specially-crafted private key, an attacker could exploit this vulnerability to execute arbitrary code on the system.

A flaw was found in bouncycastle. The OpenBSDBCrypt.checkPassword utility method compared incorrect data when checking the password allowing incorrect passwords to indicate they were matching with previously hashed ones that were different. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.

Bouncy Castle JCE Provider could provide weaker than expected security, caused by a flaw in the DSA key pair generator. A remote attacker could exploit this vulnerability to launch further attacks.

In the Bouncy Castle JCE Provider version 1.55 and earlier ECDSA does not fully validate ASN.1 encoding of signature on verification. It is possible to inject extra elements in the sequence making up the signature and still have it validate, which in some cases may allow the introduction of 'invisible' data into a signed structure.

Upstream patch:

https://github.com/bcgit/bc-java/commit/843c2e60f67d71faf81d236f448ebbe56c62c647#diff-25c3c78db788365f36839b3f2d3016b9

In Bouncy Castle JCE Provider version 1.55 and earlier the DSA does not fully validate ASN.1 encoding of signature on verification. It is possible to inject extra elements in the sequence making up the signature and still have it validate, which in some cases may allow the introduction of 'invisible' data into a signed structure.

Bouncy Castle BC 1.54 - 1.59, BC-FJA 1.0.0, BC-FJA 1.0.1 and earlier have a flaw in the Low-level interface to RSA key pair generator, specifically RSA Key Pairs generated in low-level API with added certainty may have less M-R tests than expected. This appears to be fixed in versions BC 1.60 beta 4 and later, BC-FJA 1.0.2 and later.

In the Bouncy Castle JCE Provider versions 1.51 to 1.55, a carry propagation bug was introduced in the implementation of squaring for several raw math classes have been fixed (org.bouncycastle.math.raw.Nat???). These classes are used by our custom elliptic curve implementations (org.bouncycastle.math.ec.custom.), so there was the possibility of rare (in general usage) spurious calculations for elliptic curve scalar multiplications. Such errors would have been detected with high probability by the output validation for our scalar multipliers.

The ASN.1 parser in Bouncy Castle Crypto (aka BC Java) 1.63 can trigger a large attempted memory allocation, and resultant OutOfMemoryError error, via crafted ASN.1 data. This is fixed in 1.64.

Bouncy Castle JCE Provider could provide weaker than expected security, caused by a flaw in the DSA signature generation. A remote attacker could exploit this vulnerability to launch timing attacks.

Bouncy Castle JCE Provider could provide weaker than expected security, caused by an environment where timings can be easily observed. A remote attacker could exploit this vulnerability to conduct a padding oracle attack.

Bouncy Castle JCE Provider could allow a remote attacker to obtain sensitive information, caused by a flaw in the other party DH public key. A remote attacker could exploit this vulnerability to reveal details via invalid keys.

Bouncy Castle JCE Provider could allow a remote attacker to obtain sensitive information, caused by a flaw in the AESEngine. An attacker could exploit this vulnerability to obtain sensitive information.

A flaw in how TLS/DTLS, when CBC-mode encryption is used, communicates was reported. This vulnerability can allow for a Man-in-the-Middle attacker to recover plaintext from a TLS/DTLS connection, when CBC-mode encryption is used.

This flaw is in the TLS specification, and not a bug in a specific implementation (as such, it affects nearly all implementations). As such, it affects all TLS and DTLS implementations that are compliant with TLS 1.1 or 1.2, or with DTLS 1.0 or 1.2. It also applies to implementations of SSL 3.0 and TLS 1.0 that incorporate countermeasures to deal with previous padding oracle attacks. All TLS/DTLS ciphersuites that include CBC-mode encryption are potentially vulnerable.

The paper indicates that with OpenSSL, a full plaintext recovery attack is possible, and with GnuTLS, a partial plaintext recovery is possible (recovering up to 4 bits of the last byte in any block of plaintext).

To perform a successful attack, when TLS is used, a large number of TLS sessions are required (target plaintext must be sent repeatedly in the same position in the plaintext stream across the sessions). For DTLS, a successful attack can be carried out in a single session. The attacker must also be located close to the machine being attacked.

Further details are noted in the paper.

Current status of fixes in various implementations:

OpenSSL has a patch in development NSS has a patch in development GnuTLS is fixed in versions 2.12.23, 3.0.28, and 3.1.7 PolarSSL is fixed in version 1.2.5 BouncyCastle has a patch that will be included in the forthcoming 1.48 version

External References:

http://www.isg.rhul.ac.uk/tls/ http://www.isg.rhul.ac.uk/tls/TLStiming.pdf

Affected versions of the package are vulnerable to Hash Collision due to an error in the BKS version 1 keystore files.

BKS is a keystore format, designed to function similarly to a Sun/Oracle JKS keystore. BKS files can contain public keys, private keys and certificates, and they rely on a password-based encryption to provide confidentiality and integrity protections to the keystore contents.

The first version of a BKS file (aka BKS-V1) contained a design flaw when determining the key size used to protect the keystore data. It used the SHA-1 hash function, which is 160 bits in length. In a RFC7292-compliant cryptographic algorithm, the MAC key size should be the same size as the hash function being used, meaning that the MAC key size should be 160 bits long for BKS files.

However, Bouncy Castle BKS-V1 files uses only 16 bits for the MAC key size. Regardless of the complexity of the password, ghe BKS-V1 file will have merely 65,536 different encryption keys. An attacker may bruteforce this password in a matter of seconds by testing all 65K values.

References:

https://insights.sei.cmu.edu/cert/2018/03/the-curious-case-of-the-bouncy-castle-bks-passwords.html https://www.kb.cert.org/vuls/id/306792