Bug 1563749 (CVE-2018-5382)

Summary:	CVE-2018-5382 bouncycastle: BKS-V1 keystore files vulnerable to trivial hash collisions
Product:	[Other] Security Response	Reporter:	Andrej Nemec <anemec>
Component:	vulnerability	Assignee:	Red Hat Product Security <security-response-team>
Status:	CLOSED ERRATA	QA Contact:
Severity:	low	Docs Contact:
Priority:	low
Version:	unspecified	CC:	barracks510, bcourt, bkearney, bmaxwell, bmcclain, cbillett, cdewolf, chazlett, csutherl, darran.lofthouse, dblechte, dfediuck, dimitris, dosoudil, drieden, eedri, ganandan, hhorak, jawilson, jjohnstn, jmatthew, jochrist, jolee, jorton, jschatte, jshepherd, jstastny, jwon, kseifried, lgao, mgoldboi, michal.skrivanek, mmccune, mrike, myarboro, ohadlevy, pavelp, pgier, psakar, pslavice, psotirop, puntogil, rchan, rgrunber, rnetuka, rsvoboda, sbonazzo, sherold, steve.traylen, swoodman, tomckay, tsanders, twalsh, vhalbert, vtunka, ykaul
Target Milestone:	---	Keywords:	Reopened, Security
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	bouncycastle 1.47	Doc Type:	If docs needed, set a value
Doc Text:	A flaw involving a risky cryptographic algorithm was found in Bouncycastle. BKS-V1 contained a design flaw resulting from using the SHA-1 hash function, as it contains a 16-bit MAC key size and a 160-bit SHA-1 hash function. This flaw allows an attacker to brute force the password due to the trivial hash collisions, resulting in a loss of confidentiality and integrity.	Story Points:	---
Clone Of:		Environment:
Last Closed:	2019-06-10 10:19:38 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	1564247, 1564248
Bug Blocks:	1563752, 2076448

Description Andrej Nemec 2018-04-04 15:21:21 UTC

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

Comment 3 Andrej Nemec 2018-05-14 15:51:47 UTC

Statement:

Red Hat Product Security has rated this issue as having security impact of Low. This issue is not currently planned to be addressed in future updates. For additional information, refer to the Issue Severity Classification: https://access.redhat.com/security/updates/classification/.

Comment 4 Doran Moppert 2018-05-28 06:33:56 UTC

Note that per the cert advisory, bouncycastle 1.49 re-introduced the legacy signature format as an option, calling it "BKS-1".  Version 1.49 and newer should avoid using this form for keystore verification.

Comment 5 Tomas Hoger 2018-06-18 13:11:30 UTC

This flaw affected BKS (Bouncy Castle keystore) version 1.  It was fixed in Bouncy Castle version 1.47.  However, as the fix implies a change to the keystore format, the new format is referred to as BKS version 2.  The support for BKS version 1 was re-introduced again in Bouncy Castle version 1.49 (most likely because of backwards (in)compatibility concerns), however BKS version 2 remains the default.  Applications using Bouncy Castle 1.49 or later may be affected if the explicitly request the use of BKS-V1 keystore format would still be affected by this issue.

Relevant entries form the Bouncy Castle release notes:

https://www.bouncycastle.org/releasenotes.html

1.47:
The default MAC for a BKS key store was 2 bytes, this has been upgraded to 20 bytes.

1.49:
A new KeyStore type, BKS-V1, has been added for people needing to create key stores compatible with earlier versions of Bouncy Castle.

Comment 11 errata-xmlrpc 2018-10-16 15:22:06 UTC

This issue has been addressed in the following products:

  Red Hat Satellite 6.4 for RHEL 7

Via RHSA-2018:2927 https://access.redhat.com/errata/RHSA-2018:2927

Comment 12 Joshua Padman 2019-05-23 10:16:01 UTC

This vulnerability is out of security support scope for the following product:
 * Red Hat JBoss Data Virtualization & Services 6

Please refer to https://access.redhat.com/support/policy/updates/jboss_notes for more details.

Comment 14 Jonathan Christison 2020-05-19 09:23:22 UTC

AMQ-ST ships with a version of bouncycastle that contains the functionality to create a BKS-V1 keystore, however there is nothing in AMQ-ST that utilises this vulnerable keystore format.