CVE-2018-5382
published 2018-04-16CVE-2018-5382: The default BKS keystore use an HMAC that is only 16 bits long, which can allow an attacker to compromise the integrity of a BKS keystore. Bouncy Castle…
PriorityP418medium4.4CVSS 3.1
AVLACLPRLUINSUCLILAN
EPSS
0.26%
17.7th percentile
The default BKS keystore use an HMAC that is only 16 bits long, which can allow an attacker to compromise the integrity of a BKS keystore. Bouncy Castle release 1.47 changes the BKS format to a format which uses a 160 bit HMAC instead. This applies to any BKS keystore generated prior to BC 1.47. For situations where people need to create the files for legacy reasons a specific keystore type "BKS-V1" was introduced in 1.49. It should be noted that the use of "BKS-V1" is discouraged by the library authors and should only be used where it is otherwise safe to do so, as in where the use of a 16 bit checksum for the file integrity check is not going to cause a security issue in itself.
Affected
5 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| bouncycastle | bc-java | <= 1.49 | — |
| debian | bouncycastle | < bouncycastle 1.48+dfsg-2 (bookworm) | bouncycastle 1.48+dfsg-2 (bookworm) |
| legion_of_the_bouncy_castle | bouncy_castle | >= all < 1.47 | 1.47 |
| redhat | satellite | — | — |
| redhat | satellite_capsule | — | — |
CVSS provenance
nvdv3.14.4MEDIUMCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N
nvdv2.03.6LOWAV:L/AC:L/Au:N/C:P/I:P/A:N
osv4.4MEDIUM
vendor_debian4.4MEDIUM
vendor_redhat4.4MEDIUM
Stop checking back — get the weekly exploitation signal.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
Debian
CVE-2018-5382: bouncycastle - The default BKS keystore use an HMAC that is only 16 bits long, which can allow ...
vendor_debian·2018·CVSS 4.4
CVE-2018-5382 [MEDIUM] CVE-2018-5382: bouncycastle - The default BKS keystore use an HMAC that is only 16 bits long, which can allow ...
The default BKS keystore use an HMAC that is only 16 bits long, which can allow an attacker to compromise the integrity of a BKS keystore. Bouncy Castle release 1.47 changes the BKS format to a format which uses a 160 bit HMAC instead. This applies to any BKS keystore generated prior to BC 1.47. For situations where people need to create the files for legacy reasons a specific keystore type "BKS-V1" was introduced in 1.49. It should be noted that the use of "BKS-V1" is discouraged by the library authors and should only be used where it is otherwise safe to do so, as in where the use of a 16 bit checksum for the file integrity check is not going to cause a security issue in itself.
Scope: local
bookworm: resolved (fixed in 1.48+dfsg-2)
bullseye: resolved (fixed in 1.48+dfsg-2)
forky: resolv
Red Hat
bouncycastle: BKS-V1 keystore files vulnerable to trivial hash collisions
vendor_redhat·2012-03-30·CVSS 4.4
CVE-2018-5382 [MEDIUM] CWE-327 bouncycastle: BKS-V1 keystore files vulnerable to trivial hash collisions
bouncycastle: BKS-V1 keystore files vulnerable to trivial hash collisions
The default BKS keystore use an HMAC that is only 16 bits long, which can allow an attacker to compromise the integrity of a BKS keystore. Bouncy Castle release 1.47 changes the BKS format to a format which uses a 160 bit HMAC instead. This applies to any BKS keystore generated prior to BC 1.47. For situations where people need to create the files for legacy reasons a specific keystore type "BKS-V1" was introduced in 1.49. It should be noted that the use of "BKS-V1" is discouraged by the library authors and should only be used where it is otherwise safe to do so, as in where the use of a 16 bit checksum for the file integrity check is not going to cause a security issue in itself.
A flaw involving a risky cryptogra
GHSA
Improper Validation of Integrity Check Value in Bouncy Castle
ghsa·2022-05-13
CVE-2018-5382 [MEDIUM] CWE-354 Improper Validation of Integrity Check Value in Bouncy Castle
Improper Validation of Integrity Check Value in Bouncy Castle
The default BKS keystore use an HMAC that is only 16 bits long, which can allow an attacker to compromise the integrity of a BKS keystore. Bouncy Castle release 1.47 changes the BKS format to a format which uses a 160 bit HMAC instead. This applies to any BKS keystore generated prior to BC 1.47. For situations where people need to create the files for legacy reasons a specific keystore type "BKS-V1" was introduced in 1.49. It should be noted that the use of "BKS-V1" is discouraged by the library authors and should only be used where it is otherwise safe to do so, as in where the use of a 16 bit checksum for the file integrity check is not going to cause a security issue in itself.
OSV
Improper Validation of Integrity Check Value in Bouncy Castle
osv·2022-05-13
CVE-2018-5382 [MEDIUM] Improper Validation of Integrity Check Value in Bouncy Castle
Improper Validation of Integrity Check Value in Bouncy Castle
The default BKS keystore use an HMAC that is only 16 bits long, which can allow an attacker to compromise the integrity of a BKS keystore. Bouncy Castle release 1.47 changes the BKS format to a format which uses a 160 bit HMAC instead. This applies to any BKS keystore generated prior to BC 1.47. For situations where people need to create the files for legacy reasons a specific keystore type "BKS-V1" was introduced in 1.49. It should be noted that the use of "BKS-V1" is discouraged by the library authors and should only be used where it is otherwise safe to do so, as in where the use of a 16 bit checksum for the file integrity check is not going to cause a security issue in itself.
OSV
CVE-2018-5382: The default BKS keystore use an HMAC that is only 16 bits long, which can allow an attacker to compromise the integrity of a BKS keystore
osv·2018-04-16·CVSS 4.4
CVE-2018-5382 [MEDIUM] CVE-2018-5382: The default BKS keystore use an HMAC that is only 16 bits long, which can allow an attacker to compromise the integrity of a BKS keystore
The default BKS keystore use an HMAC that is only 16 bits long, which can allow an attacker to compromise the integrity of a BKS keystore. Bouncy Castle release 1.47 changes the BKS format to a format which uses a 160 bit HMAC instead. This applies to any BKS keystore generated prior to BC 1.47. For situations where people need to create the files for legacy reasons a specific keystore type "BKS-V1" was introduced in 1.49. It should be noted that the use of "BKS-V1" is discouraged by the library authors and should only be used where it is otherwise safe to do so, as in where the use of a 16 bit checksum for the file integrity check is not going to cause a security issue in itself.
No detection rules found.
No public exploits indexed.
http://www.securityfocus.com/bid/103453https://access.redhat.com/errata/RHSA-2018:2927https://www.bouncycastle.org/releasenotes.htmlhttps://www.kb.cert.org/vuls/id/306792https://www.oracle.com/security-alerts/cpuoct2020.htmlhttp://www.securityfocus.com/bid/103453https://access.redhat.com/errata/RHSA-2018:2927https://www.bouncycastle.org/releasenotes.htmlhttps://www.kb.cert.org/vuls/id/306792https://www.oracle.com/security-alerts/cpuoct2020.html
2018-04-16
Published