gsd-2017-9106
Vulnerability from gsd
Modified
2023-12-13 01:21
Details
An issue was discovered in adns before 1.5.2. adns_rr_info mishandles a bogus *datap. The general pattern for formatting integers is to sprintf into a fixed-size buffer. This is correct if the input is in the right range; if it isn't, the buffer may be overrun (depending on the sizes of the types on the current platform). Of course the inputs ought to be right. And there are pointers in there too, so perhaps one could say that the caller ought to check these things. It may be better to require the caller to make the pointer structure right, but to have the code here be defensive about (and tolerate with an error but without crashing) out-of-range integer values. So: it should defend each of these integer conversion sites with a check for the actual permitted range, and return adns_s_invaliddata if not. The lack of this check causes the SOA sign extension bug to be a serious security problem: the sign extended SOA value is out of range, and overruns the buffer when reconverted. This is related to sign extending SOA 32-bit integer fields, and use of a signed data type.
Aliases
Aliases
{
"GSD": {
"alias": "CVE-2017-9106",
"description": "An issue was discovered in adns before 1.5.2. adns_rr_info mishandles a bogus *datap. The general pattern for formatting integers is to sprintf into a fixed-size buffer. This is correct if the input is in the right range; if it isn\u0027t, the buffer may be overrun (depending on the sizes of the types on the current platform). Of course the inputs ought to be right. And there are pointers in there too, so perhaps one could say that the caller ought to check these things. It may be better to require the caller to make the pointer structure right, but to have the code here be defensive about (and tolerate with an error but without crashing) out-of-range integer values. So: it should defend each of these integer conversion sites with a check for the actual permitted range, and return adns_s_invaliddata if not. The lack of this check causes the SOA sign extension bug to be a serious security problem: the sign extended SOA value is out of range, and overruns the buffer when reconverted. This is related to sign extending SOA 32-bit integer fields, and use of a signed data type.",
"id": "GSD-2017-9106",
"references": [
"https://www.suse.com/security/cve/CVE-2017-9106.html"
]
},
"gsd": {
"metadata": {
"exploitCode": "unknown",
"remediation": "unknown",
"reportConfidence": "confirmed",
"type": "vulnerability"
},
"osvSchema": {
"aliases": [
"CVE-2017-9106"
],
"details": "An issue was discovered in adns before 1.5.2. adns_rr_info mishandles a bogus *datap. The general pattern for formatting integers is to sprintf into a fixed-size buffer. This is correct if the input is in the right range; if it isn\u0027t, the buffer may be overrun (depending on the sizes of the types on the current platform). Of course the inputs ought to be right. And there are pointers in there too, so perhaps one could say that the caller ought to check these things. It may be better to require the caller to make the pointer structure right, but to have the code here be defensive about (and tolerate with an error but without crashing) out-of-range integer values. So: it should defend each of these integer conversion sites with a check for the actual permitted range, and return adns_s_invaliddata if not. The lack of this check causes the SOA sign extension bug to be a serious security problem: the sign extended SOA value is out of range, and overruns the buffer when reconverted. This is related to sign extending SOA 32-bit integer fields, and use of a signed data type.",
"id": "GSD-2017-9106",
"modified": "2023-12-13T01:21:07.943880Z",
"schema_version": "1.4.0"
}
},
"namespaces": {
"cve.org": {
"CVE_data_meta": {
"ASSIGNER": "cve@mitre.org",
"ID": "CVE-2017-9106",
"STATE": "PUBLIC"
},
"affects": {
"vendor": {
"vendor_data": [
{
"product": {
"product_data": [
{
"product_name": "n/a",
"version": {
"version_data": [
{
"version_value": "n/a"
}
]
}
}
]
},
"vendor_name": "n/a"
}
]
}
},
"data_format": "MITRE",
"data_type": "CVE",
"data_version": "4.0",
"description": {
"description_data": [
{
"lang": "eng",
"value": "An issue was discovered in adns before 1.5.2. adns_rr_info mishandles a bogus *datap. The general pattern for formatting integers is to sprintf into a fixed-size buffer. This is correct if the input is in the right range; if it isn\u0027t, the buffer may be overrun (depending on the sizes of the types on the current platform). Of course the inputs ought to be right. And there are pointers in there too, so perhaps one could say that the caller ought to check these things. It may be better to require the caller to make the pointer structure right, but to have the code here be defensive about (and tolerate with an error but without crashing) out-of-range integer values. So: it should defend each of these integer conversion sites with a check for the actual permitted range, and return adns_s_invaliddata if not. The lack of this check causes the SOA sign extension bug to be a serious security problem: the sign extended SOA value is out of range, and overruns the buffer when reconverted. This is related to sign extending SOA 32-bit integer fields, and use of a signed data type."
}
]
},
"problemtype": {
"problemtype_data": [
{
"description": [
{
"lang": "eng",
"value": "n/a"
}
]
}
]
},
"references": {
"reference_data": [
{
"name": "http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?p=adns.git",
"refsource": "MISC",
"url": "http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?p=adns.git"
},
{
"name": "https://www.chiark.greenend.org.uk/pipermail/adns-announce/2020/000004.html",
"refsource": "CONFIRM",
"url": "https://www.chiark.greenend.org.uk/pipermail/adns-announce/2020/000004.html"
},
{
"name": "http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?p=adns.git;a=blob;f=changelog",
"refsource": "CONFIRM",
"url": "http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?p=adns.git;a=blob;f=changelog"
},
{
"name": "FEDORA-2020-530188bf36",
"refsource": "FEDORA",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/TRVHN3GGVNQWAOL3PWC5FLAV7HUESLZR/"
},
{
"name": "FEDORA-2020-e59bcaf702",
"refsource": "FEDORA",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/UGFZ4SPV6KFQK6ZNUZFB5Y32OYFOM5YJ/"
}
]
}
},
"nvd.nist.gov": {
"configurations": {
"CVE_data_version": "4.0",
"nodes": [
{
"children": [],
"cpe_match": [
{
"cpe23Uri": "cpe:2.3:a:gnu:adns:*:*:*:*:*:*:*:*",
"cpe_name": [],
"versionEndExcluding": "1.5.2",
"vulnerable": true
}
],
"operator": "OR"
},
{
"children": [],
"cpe_match": [
{
"cpe23Uri": "cpe:2.3:o:fedoraproject:fedora:31:*:*:*:*:*:*:*",
"cpe_name": [],
"vulnerable": true
},
{
"cpe23Uri": "cpe:2.3:o:fedoraproject:fedora:32:*:*:*:*:*:*:*",
"cpe_name": [],
"vulnerable": true
}
],
"operator": "OR"
}
]
},
"cve": {
"CVE_data_meta": {
"ASSIGNER": "cve@mitre.org",
"ID": "CVE-2017-9106"
},
"data_format": "MITRE",
"data_type": "CVE",
"data_version": "4.0",
"description": {
"description_data": [
{
"lang": "en",
"value": "An issue was discovered in adns before 1.5.2. adns_rr_info mishandles a bogus *datap. The general pattern for formatting integers is to sprintf into a fixed-size buffer. This is correct if the input is in the right range; if it isn\u0027t, the buffer may be overrun (depending on the sizes of the types on the current platform). Of course the inputs ought to be right. And there are pointers in there too, so perhaps one could say that the caller ought to check these things. It may be better to require the caller to make the pointer structure right, but to have the code here be defensive about (and tolerate with an error but without crashing) out-of-range integer values. So: it should defend each of these integer conversion sites with a check for the actual permitted range, and return adns_s_invaliddata if not. The lack of this check causes the SOA sign extension bug to be a serious security problem: the sign extended SOA value is out of range, and overruns the buffer when reconverted. This is related to sign extending SOA 32-bit integer fields, and use of a signed data type."
}
]
},
"problemtype": {
"problemtype_data": [
{
"description": [
{
"lang": "en",
"value": "CWE-119"
}
]
}
]
},
"references": {
"reference_data": [
{
"name": "http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?p=adns.git;a=blob;f=changelog",
"refsource": "CONFIRM",
"tags": [
"Release Notes"
],
"url": "http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?p=adns.git;a=blob;f=changelog"
},
{
"name": "https://www.chiark.greenend.org.uk/pipermail/adns-announce/2020/000004.html",
"refsource": "CONFIRM",
"tags": [
"Release Notes",
"Third Party Advisory"
],
"url": "https://www.chiark.greenend.org.uk/pipermail/adns-announce/2020/000004.html"
},
{
"name": "http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?p=adns.git",
"refsource": "MISC",
"tags": [
"Third Party Advisory"
],
"url": "http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?p=adns.git"
},
{
"name": "FEDORA-2020-530188bf36",
"refsource": "FEDORA",
"tags": [
"Mailing List",
"Third Party Advisory"
],
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/TRVHN3GGVNQWAOL3PWC5FLAV7HUESLZR/"
},
{
"name": "FEDORA-2020-e59bcaf702",
"refsource": "FEDORA",
"tags": [
"Mailing List",
"Third Party Advisory"
],
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/UGFZ4SPV6KFQK6ZNUZFB5Y32OYFOM5YJ/"
}
]
}
},
"impact": {
"baseMetricV2": {
"acInsufInfo": false,
"cvssV2": {
"accessComplexity": "LOW",
"accessVector": "NETWORK",
"authentication": "NONE",
"availabilityImpact": "PARTIAL",
"baseScore": 5.0,
"confidentialityImpact": "NONE",
"integrityImpact": "NONE",
"vectorString": "AV:N/AC:L/Au:N/C:N/I:N/A:P",
"version": "2.0"
},
"exploitabilityScore": 10.0,
"impactScore": 2.9,
"obtainAllPrivilege": false,
"obtainOtherPrivilege": false,
"obtainUserPrivilege": false,
"severity": "MEDIUM",
"userInteractionRequired": false
},
"baseMetricV3": {
"cvssV3": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "HIGH",
"baseScore": 7.5,
"baseSeverity": "HIGH",
"confidentialityImpact": "NONE",
"integrityImpact": "NONE",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"version": "3.1"
},
"exploitabilityScore": 3.9,
"impactScore": 3.6
}
},
"lastModifiedDate": "2023-01-28T01:04Z",
"publishedDate": "2020-06-18T14:15Z"
}
}
}
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.
Loading…
Loading…