add CVE-2020-4060 for GHSA-v9ph-r496-4m2j

This commit is contained in:
Robert Schultheis 2020-06-22 09:42:41 -06:00
parent 0f134eb65f
commit af23de823c
No known key found for this signature in database
GPG Key ID: 348C4211B4D8BB40

View File

@ -1,18 +1,83 @@
{
"data_type": "CVE",
"data_format": "MITRE",
"data_version": "4.0",
"CVE_data_meta": {
"ASSIGNER": "security-advisories@github.com",
"ID": "CVE-2020-4060",
"ASSIGNER": "cve@mitre.org",
"STATE": "RESERVED"
"STATE": "PUBLIC",
"TITLE": "Use After Free in in cups_update_info in LoRa Basics Station"
},
"affects": {
"vendor": {
"vendor_data": [
{
"product": {
"product_data": [
{
"product_name": "LoRa Basics Station",
"version": {
"version_data": [
{
"version_value": "< 2.0.4"
}
]
}
}
]
},
"vendor_name": "LoRa Basics"
}
]
}
},
"data_format": "MITRE",
"data_type": "CVE",
"data_version": "4.0",
"description": {
"description_data": [
{
"lang": "eng",
"value": "** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem. When the candidate has been publicized, the details for this candidate will be provided."
"value": "In LoRa Basics Station before 2.0.4, there is a Use After Free vulnerability that leads to memory corruption.\n\nThis bug is triggered on 32-bit machines when the CUPS server responds with a message (https://doc.sm.tc/station/cupsproto.html#http-post-response) where the signature length is larger than 2 GByte (never happens in practice), or the response is crafted specifically to trigger this issue (i.e. the length signature field indicates a value larger than (2**31)-1 although the signature actually does not contain that much data). In such a scenario, on 32 bit machines, Basic Station would execute a code path, where a piece of memory is accessed after it has been freed, causing the process to crash and restarted again.\n\nThe CUPS transaction is typically mutually authenticated over TLS. Therefore, in order to trigger this vulnerability, the attacker would have to gain access to the CUPS server first. If the user chose to operate without authentication over TLS but yet is concerned about this vulnerability, one possible workaround is to enable TLS authentication.\n\nThis has been fixed in 2.0.4."
}
]
},
"impact": {
"cvss": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "LOW",
"baseScore": 4.1,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "NONE",
"integrityImpact": "NONE",
"privilegesRequired": "LOW",
"scope": "CHANGED",
"userInteraction": "REQUIRED",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:N/I:N/A:L",
"version": "3.1"
}
},
"problemtype": {
"problemtype_data": [
{
"description": [
{
"lang": "eng",
"value": "CWE-416: Use After Free"
}
]
}
]
},
"references": {
"reference_data": [
{
"name": "https://github.com/lorabasics/basicstation/security/advisories/GHSA-v9ph-r496-4m2j",
"refsource": "CONFIRM",
"url": "https://github.com/lorabasics/basicstation/security/advisories/GHSA-v9ph-r496-4m2j"
}
]
},
"source": {
"advisory": "GHSA-v9ph-r496-4m2j",
"discovery": "UNKNOWN"
}
}