Critical Vulnerability in Bouncy Castle: CVE-2018-5382

Sonatype Intelligence Insights: CVE-2018-5382 Bouncycastle Information Exposure

December 26, 2019
By Elisa Velarde

5 minute read time

For our last Sonatype Intelligence Insight of 2019, we'll cover a component vulnerability discovered in a not-so-happy accident that appears far more dangerous than the researcher had previously hypothesized.

The back story starts with Carnegie Mellon University SEI researcher Will Dormann who was researching brute force password discovery and how the Bouncy Castle BKS version 1 file is vulnerable to a brute force breach using associated metadata with a file format kept largely unprotected by default. The empirical results of his experiment are both expected and unexpected and will hopefully help developers and security professionals alike, stay ahead of the threat this component potentially poses. We'll dig into the attack mechanics, the unintended find and what developers can do to remediate.

Name of Vulnerability/Sonatype ID: CVE-2018-5382

Type of Vulnerability: Information Exposure

Severity: 9.8

CVSS 3.0 Metrics: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Components Affected:

Vulnerability Description:

The bouncycastle package is vulnerable to Information Exposure due to inadequate encryption strength. The engineLoad() function in the JDKKeyStore.class file uses BKS version 1 (which utilizes a 16-bit HMAC hash) which is not safe. This flaw allows an attacker to brute-force and derive sensitive values which can be used to compromise security or perform timing attacks.

Attack Mechanics:

Timing and side-channel attacks work by an attacker being able to deduce a secret by brute-forcing multiple values observing the time it takes for the processor to validate an incorrect answer from a correct one and return a response. This can, over time, deduce the secret or enough data for the attacker to be able to deduce the secret value.

In this particular case, the inadequate encryption length uses a 16-bit HMAC (hash) which, given the processing technology and hardware resources today, would be relatively trivial to brute-force for an attacker.

Image credit: https://insights.sei.cmu.edu/cert/2018/03/the-curious-case-of-the-bouncy-castle-bks-passwords.html

The findings were surprising, however, when the same script ran concurrently on multiple resources using the "ProcessPoolExecutor" class as a means to optimize brute-forcing. This happened by accident as the researcher forgot to terminate the script once it had found a successful password guess. The result? Multiple, different passwords were revealed for the same file as the script kept on running.

How could this be possible? Multiple passwords for the same file?

This led the researcher to suspect if there was a strong possibility of hash collisions going on.

In most mainstream hashing algorithms being used today, such as SHA-256, or even those considered cryptographically weak like MD5, the chance of a hash collision i.e. that two different strings (of passwords) yielding the exact same or similar hash values is infinitesimally small for most cases. Although HMAC algorithms like SHA-1 have been proven to be susceptible to collisions, such a collision requires a very high processing power in practice, that is, "the equivalent processing power as 6,500 years of single-CPU computations and 110 years of single-GPU computations."

Given the computation resources available today and in the last decade, 16-bit is by no means an adequate length when it comes to assuring password security. In 1996 alone, MD5 with its 128-bit key length was shown to be insecure and prone to collisions. This is why an HMAC securing passwords with a key length even 8 times smaller than that of MD5 would be catastrophic.

Additional insight comes from Will Dormann who wrote in his piece The Curious Case of the Bouncy Castle BKS Passwords,

"In the case of hashlib.sha1, the digest_size is 20 bytes (160 bits). But where it gets interesting is the derivation of hmac_key. The size of hmac_key is determined by hmac_key_size//8 (integer division, dropping any remainder). In this case, it's 20//8, which is 2 bytes (16 bits). Why is there integer division by 8 at all? It's not clear, but perhaps the developer confused where bits are used and bytes are used in the code."

Remediation Recommendation:

For users of org.bouncycastle:bcprov-jdk14 and org.bouncycastle:bcprov-jdk15on components, upgrading to version 1.47 is the recommended solution. However, a  fixed version for org.bouncycastle:bcprov-jdk16 component does not exist in Maven Central as of writing this piece.

In the fixed versions of Bouncycastle - i.e. 1.47 or newer, the BKS keystore format was updated to version 2, which uses a more rigorous HMAC of length 160-bit. This effectively resolves CVE-2018-5382.

Written by Elisa Velarde

Elisa was a Senior Product Marketing Manager at Sonatype. She brought over 10 years of experience in sourcing, mentoring, and leading Marketing or full Agile product teams while maintaining a collaborative, cross-departmental approach to support company goals.