GHSA-6xx3-rg99-gc3p CVE-2020-15522
Timing based private key exposure in Bouncy Castle
Medium
MavenNuGet
- Severity
- 5.1 / 10
- Medium · CVSS 3.1
- Exploit chance (EPSS)
- 1.52%
- Chance of exploitation in the next 30 days. Higher than 74.63% of scored vulnerabilities.
- Known exploited
- No
- Not in CISA's catalog
- Weakness
- CWE-203 Observable Discrepancy
- CWE-362 Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')
- Fix
- Available
- 9 packages have a fixed version
Description
Bouncy Castle BC Java before 1.66, BC C# .NET before 1.8.7, BC-FJA before 1.0.2.1, BC before 1.66, BC-FNA before 1.0.1.1 have a timing issue within the EC math library that can expose information about the private key when an attacker is able to observe timing information for the generation of multiple deterministic ECDSA signatures.
Affected versions
Maven
| Package | Vulnerable | Fixed in |
|---|---|---|
| org.bouncycastle:bc-fips | < 1.0.2.1 |
1.0.2.1 |
| org.bouncycastle:bcprov-ext-jdk15on | < 1.66 |
1.66 |
| org.bouncycastle:bcprov-ext-jdk16 | < 1.66 |
1.66 |
| org.bouncycastle:bcprov-jdk14 | < 1.66 |
1.66 |
| org.bouncycastle:bcprov-jdk15 | < 1.66 |
1.66 |
| org.bouncycastle:bcprov-jdk15on | < 1.66 |
1.66 |
| org.bouncycastle:bcprov-jdk15to18 | < 1.66 |
1.66 |
| org.bouncycastle:bcprov-jdk16 | < 1.66 |
1.66 |
NuGet
| Package | Vulnerable | Fixed in |
|---|---|---|
| BouncyCastle | < 1.8.7 |
1.8.7 |
How to fix
Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.
org.bouncycastle:bc-fips Maven → 1.0.2.1
- maven
<dependency><groupId>org.bouncycastle</groupId><artifactId>bc-fips</artifactId><version>1.0.2.1</version></dependency>- gradle
implementation("org.bouncycastle:bc-fips:1.0.2.1")
org.bouncycastle:bcprov-ext-jdk15on Maven → 1.66
- maven
<dependency><groupId>org.bouncycastle</groupId><artifactId>bcprov-ext-jdk15on</artifactId><version>1.66</version></dependency>- gradle
implementation("org.bouncycastle:bcprov-ext-jdk15on:1.66")
org.bouncycastle:bcprov-ext-jdk16 Maven → 1.66
- maven
<dependency><groupId>org.bouncycastle</groupId><artifactId>bcprov-ext-jdk16</artifactId><version>1.66</version></dependency>- gradle
implementation("org.bouncycastle:bcprov-ext-jdk16:1.66")
org.bouncycastle:bcprov-jdk14 Maven → 1.66
- maven
<dependency><groupId>org.bouncycastle</groupId><artifactId>bcprov-jdk14</artifactId><version>1.66</version></dependency>- gradle
implementation("org.bouncycastle:bcprov-jdk14:1.66")
org.bouncycastle:bcprov-jdk15 Maven → 1.66
- maven
<dependency><groupId>org.bouncycastle</groupId><artifactId>bcprov-jdk15</artifactId><version>1.66</version></dependency>- gradle
implementation("org.bouncycastle:bcprov-jdk15:1.66")
org.bouncycastle:bcprov-jdk15on Maven → 1.66
- maven
<dependency><groupId>org.bouncycastle</groupId><artifactId>bcprov-jdk15on</artifactId><version>1.66</version></dependency>- gradle
implementation("org.bouncycastle:bcprov-jdk15on:1.66")
org.bouncycastle:bcprov-jdk15to18 Maven → 1.66
- maven
<dependency><groupId>org.bouncycastle</groupId><artifactId>bcprov-jdk15to18</artifactId><version>1.66</version></dependency>- gradle
implementation("org.bouncycastle:bcprov-jdk15to18:1.66")
org.bouncycastle:bcprov-jdk16 Maven → 1.66
- maven
<dependency><groupId>org.bouncycastle</groupId><artifactId>bcprov-jdk16</artifactId><version>1.66</version></dependency>- gradle
implementation("org.bouncycastle:bcprov-jdk16:1.66")
BouncyCastle NuGet → 1.8.7
- dotnet
dotnet add package BouncyCastle --version 1.8.7
Severity breakdown
CVSS 3.1 5.1
CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N
- Attack vector
- Local
- Attack complexity
- High
- Privileges required
- None
- User interaction
- None
- Scope
- Unchanged
- Confidentiality
- High
- Integrity
- None
- Availability
- None
Weakness
CWE-203: Observable Discrepancy
The product behaves differently or sends different responses under different circumstances in a way that is observable to an unauthorized actor.
How to prevent it
- Architecture and Design: Compartmentalize the system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area. Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.
- Implementation: Ensure that error messages only contain minimal details that are useful to the intended audience and no one else. The messages need to strike the balance between being too cryptic (which can confuse users) or being too detailed (which may reveal more than intended). The messages should not reveal the methods that were used to determine the error. Attackers can use detailed information to refine or optimize their original attack, thereby increasing their chances of success. If errors must be captured in some detail, record them in log messages, but consider what could occur if the log messages can be viewed by attackers. Highly sensitive information such as passwords should never be saved to log files. Avoid inconsistent messaging that might accidentally tip off an attacker about internal state, such as whether a user account exists or not.
CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')
The product contains a concurrent code sequence that requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence operating concurrently.
How to prevent it
- Architecture and Design: In languages that support it, use synchronization primitives. Only wrap these around critical code to minimize the impact on performance.
- Architecture and Design: Use thread-safe capabilities such as the data access abstraction in Spring.
- Architecture and Design: Minimize the usage of shared resources in order to remove as much complexity as possible from the control flow and to reduce the likelihood of unexpected conditions occurring. Additionally, this will minimize the amount of synchronization necessary and may even help to reduce the likelihood of a denial of service where an attacker may be able to repeatedly trigger a critical section (CWE-400).
- Implementation: When using multithreading and operating on shared variables, only use thread-safe functions.
- Implementation: Use atomic operations on shared variables. Be wary of innocent-looking constructs such as "x++". This may appear atomic at the code layer, but it is actually non-atomic at the instruction layer, since it involves a read, followed by a computation, followed by a write.
- Implementation: Use a mutex if available, but be sure to avoid related weaknesses such as CWE-412.
- Implementation: Avoid double-checked locking (CWE-609) and other implementation errors that arise when trying to avoid the overhead of synchronization.
- Implementation: Disable interrupts or signals over critical parts of the code, but also make sure that the code does not go into a large or infinite loop.
- Implementation: Use the volatile type modifier for critical variables to avoid unexpected compiler optimization or reordering. This does not necessarily solve the synchronization problem, but it can help.
- Architecture and Design, Operation: Run your code using the lowest privileges that are required to accomplish the necessary tasks [REF-76]. If possible, create isolated accounts with limited privileges that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations.
References
Advisories
Other links
Timeline
- Published
- Last updated by the source
- Latest EPSS score
Related advisories
| Advisory | Severity | Why it's related |
|---|---|---|
| GHSA-p93r-85wp-75v3 Bouncy Castle Has Covert Timing Channel Vulnerability | High | Also affects org.bouncycastle:bcprov-jdk14 |
| GHSA-c3fc-8qff-9hwx Bouncy Castle has an LDAP injection | Medium | Also affects org.bouncycastle:bcprov-jdk14 |
| GHSA-574f-3g2m-x479 Bouncy Castle for Java GOST 28147 CTR mode reuses keystream after 255 blocks | High | Also affects org.bouncycastle:bcprov-jdk14 |
| GHSA-67mf-3cr5-8w23 Bouncy Castle for Java on All (API modules) allows Excessive Allocation | Medium | Also affects org.bouncycastle:bc-fips |
| GHSA-m44j-cfrm-g8qc Bouncy Castle crafted signature and public key can be used to trigger an infinite loop | High | Also affects BouncyCastle |
| GHSA-v435-xc8x-wvr9 Bouncy Castle affected by timing side-channel for RSA key exchange ("The Marvin Attack") | Medium | Also affects BouncyCastle |
| GHSA-8xfc-gm6g-vgpv Bouncy Castle certificate parsing issues cause high CPU usage during parameter evaluation. | High | Also affects BouncyCastle |
| GHSA-4h8f-2wvx-gg5w Bouncy Castle Java Cryptography API vulnerable to DNS poisoning | High | Also affects org.bouncycastle:bcprov-jdk14 |
MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.
Check your repos with MergeHarbor