gsd-2018-5382
Vulnerability from gsd
Modified
2023-12-13 01:22
Details
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.
Aliases
Aliases
{
"GSD": {
"alias": "CVE-2018-5382",
"description": "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.",
"id": "GSD-2018-5382",
"references": [
"https://www.suse.com/security/cve/CVE-2018-5382.html",
"https://access.redhat.com/errata/RHSA-2018:2927"
]
},
"gsd": {
"metadata": {
"exploitCode": "unknown",
"remediation": "unknown",
"reportConfidence": "confirmed",
"type": "vulnerability"
},
"osvSchema": {
"aliases": [
"CVE-2018-5382"
],
"details": "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.",
"id": "GSD-2018-5382",
"modified": "2023-12-13T01:22:39.706184Z",
"schema_version": "1.4.0"
}
},
"namespaces": {
"cve.org": {
"CVE_data_meta": {
"ASSIGNER": "cert@cert.org",
"DATE_PUBLIC": "2012-03-20T00:00:00.000Z",
"ID": "CVE-2018-5382",
"STATE": "PUBLIC",
"TITLE": "Bouncy Castle BKS-V1 keystore files vulnerable to trivial hash collisions"
},
"affects": {
"vendor": {
"vendor_data": [
{
"product": {
"product_data": [
{
"product_name": "Bouncy Castle",
"version": {
"version_data": [
{
"affected": "\u003c",
"version_name": "all",
"version_value": "1.47"
}
]
}
}
]
},
"vendor_name": "Legion of the Bouncy Castle"
}
]
}
},
"data_format": "MITRE",
"data_type": "CVE",
"data_version": "4.0",
"description": {
"description_data": [
{
"lang": "eng",
"value": "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."
}
]
},
"problemtype": {
"problemtype_data": [
{
"description": [
{
"lang": "eng",
"value": "CWE-327: Use of a Broken or Risky Cryptographic Algorithm"
}
]
}
]
},
"references": {
"reference_data": [
{
"name": "103453",
"refsource": "BID",
"url": "http://www.securityfocus.com/bid/103453"
},
{
"name": "RHSA-2018:2927",
"refsource": "REDHAT",
"url": "https://access.redhat.com/errata/RHSA-2018:2927"
},
{
"name": "VU#306792",
"refsource": "CERT-VN",
"url": "https://www.kb.cert.org/vuls/id/306792"
},
{
"name": "https://www.bouncycastle.org/releasenotes.html",
"refsource": "MISC",
"url": "https://www.bouncycastle.org/releasenotes.html"
},
{
"name": "https://www.oracle.com/security-alerts/cpuoct2020.html",
"refsource": "MISC",
"url": "https://www.oracle.com/security-alerts/cpuoct2020.html"
}
]
},
"source": {
"discovery": "UNKNOWN"
}
},
"gitlab.com": {
"advisories": [
{
"affected_range": "(,1.50)",
"affected_versions": "All versions before 1.50",
"cvss_v2": "AV:L/AC:L/Au:N/C:P/I:P/A:N",
"cvss_v3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N",
"cwe_ids": [
"CWE-1035",
"CWE-354",
"CWE-937"
],
"date": "2022-06-28",
"description": "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.",
"fixed_versions": [
"1.50"
],
"identifier": "CVE-2018-5382",
"identifiers": [
"GHSA-8477-3v39-ggpm",
"CVE-2018-5382"
],
"not_impacted": "All versions starting from 1.50",
"package_slug": "maven/org.bouncycastle/bcprov-jdk15on",
"pubdate": "2022-05-13",
"solution": "Upgrade to version 1.50 or above.",
"title": "Improper Validation of Integrity Check Value",
"urls": [
"https://nvd.nist.gov/vuln/detail/CVE-2018-5382",
"https://access.redhat.com/errata/RHSA-2018:2927",
"https://www.bouncycastle.org/releasenotes.html",
"https://www.kb.cert.org/vuls/id/306792",
"https://www.oracle.com/security-alerts/cpuoct2020.html",
"http://www.securityfocus.com/bid/103453",
"https://github.com/advisories/GHSA-8477-3v39-ggpm"
],
"uuid": "dc59cfcc-5073-4b3b-affa-bea06f145b30"
}
]
},
"nvd.nist.gov": {
"configurations": {
"CVE_data_version": "4.0",
"nodes": [
{
"children": [],
"cpe_match": [
{
"cpe23Uri": "cpe:2.3:a:bouncycastle:legion-of-the-bouncy-castle-java-crytography-api:*:*:*:*:*:*:*:*",
"cpe_name": [],
"versionEndIncluding": "1.49",
"vulnerable": true
}
],
"operator": "OR"
},
{
"children": [],
"cpe_match": [
{
"cpe23Uri": "cpe:2.3:a:redhat:satellite:6.4:*:*:*:*:*:*:*",
"cpe_name": [],
"vulnerable": true
},
{
"cpe23Uri": "cpe:2.3:a:redhat:satellite_capsule:6.4:*:*:*:*:*:*:*",
"cpe_name": [],
"vulnerable": true
}
],
"operator": "OR"
}
]
},
"cve": {
"CVE_data_meta": {
"ASSIGNER": "cert@cert.org",
"ID": "CVE-2018-5382"
},
"data_format": "MITRE",
"data_type": "CVE",
"data_version": "4.0",
"description": {
"description_data": [
{
"lang": "en",
"value": "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."
}
]
},
"problemtype": {
"problemtype_data": [
{
"description": [
{
"lang": "en",
"value": "CWE-354"
}
]
}
]
},
"references": {
"reference_data": [
{
"name": "VU#306792",
"refsource": "CERT-VN",
"tags": [
"Third Party Advisory",
"US Government Resource"
],
"url": "https://www.kb.cert.org/vuls/id/306792"
},
{
"name": "https://www.bouncycastle.org/releasenotes.html",
"refsource": "MISC",
"tags": [
"Release Notes",
"Vendor Advisory"
],
"url": "https://www.bouncycastle.org/releasenotes.html"
},
{
"name": "103453",
"refsource": "BID",
"tags": [
"Third Party Advisory",
"VDB Entry"
],
"url": "http://www.securityfocus.com/bid/103453"
},
{
"name": "RHSA-2018:2927",
"refsource": "REDHAT",
"tags": [
"Third Party Advisory"
],
"url": "https://access.redhat.com/errata/RHSA-2018:2927"
},
{
"name": "https://www.oracle.com/security-alerts/cpuoct2020.html",
"refsource": "MISC",
"tags": [
"Third Party Advisory"
],
"url": "https://www.oracle.com/security-alerts/cpuoct2020.html"
}
]
}
},
"impact": {
"baseMetricV2": {
"acInsufInfo": false,
"cvssV2": {
"accessComplexity": "LOW",
"accessVector": "LOCAL",
"authentication": "NONE",
"availabilityImpact": "NONE",
"baseScore": 3.6,
"confidentialityImpact": "PARTIAL",
"integrityImpact": "PARTIAL",
"vectorString": "AV:L/AC:L/Au:N/C:P/I:P/A:N",
"version": "2.0"
},
"exploitabilityScore": 3.9,
"impactScore": 4.9,
"obtainAllPrivilege": false,
"obtainOtherPrivilege": false,
"obtainUserPrivilege": false,
"severity": "LOW",
"userInteractionRequired": false
},
"baseMetricV3": {
"cvssV3": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "NONE",
"baseScore": 4.4,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "LOW",
"integrityImpact": "LOW",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N",
"version": "3.1"
},
"exploitabilityScore": 1.8,
"impactScore": 2.5
}
},
"lastModifiedDate": "2022-04-20T15:31Z",
"publishedDate": "2018-04-16T14:29Z"
}
}
}
Loading…
Loading…
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
- Confirmed: The vulnerability is confirmed from an analyst perspective.
- Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
- Patched: This vulnerability was successfully patched by the user reporting the sighting.
- Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
- Not confirmed: The user expresses doubt about the veracity of the vulnerability.
- Not patched: This vulnerability was not successfully patched by the user reporting the sighting.