gsd-2018-5741
Vulnerability from gsd
Modified
2023-12-13 01:22
Details
To provide fine-grained controls over the ability to use Dynamic DNS (DDNS) to update records in a zone, BIND 9 provides a feature called update-policy. Various rules can be configured to limit the types of updates that can be performed by a client, depending on the key used when sending the update request. Unfortunately, some rule types were not initially documented, and when documentation for them was added to the Administrator Reference Manual (ARM) in change #3112, the language that was added to the ARM at that time incorrectly described the behavior of two rule types, krb5-subdomain and ms-subdomain. This incorrect documentation could mislead operators into believing that policies they had configured were more restrictive than they actually were. This affects BIND versions prior to BIND 9.11.5 and BIND 9.12.3.
Aliases
Aliases
{
"GSD": {
"alias": "CVE-2018-5741",
"description": "To provide fine-grained controls over the ability to use Dynamic DNS (DDNS) to update records in a zone, BIND 9 provides a feature called update-policy. Various rules can be configured to limit the types of updates that can be performed by a client, depending on the key used when sending the update request. Unfortunately, some rule types were not initially documented, and when documentation for them was added to the Administrator Reference Manual (ARM) in change #3112, the language that was added to the ARM at that time incorrectly described the behavior of two rule types, krb5-subdomain and ms-subdomain. This incorrect documentation could mislead operators into believing that policies they had configured were more restrictive than they actually were. This affects BIND versions prior to BIND 9.11.5 and BIND 9.12.3.",
"id": "GSD-2018-5741",
"references": [
"https://www.suse.com/security/cve/CVE-2018-5741.html",
"https://access.redhat.com/errata/RHSA-2019:2057",
"https://alas.aws.amazon.com/cve/html/CVE-2018-5741.html",
"https://linux.oracle.com/cve/CVE-2018-5741.html"
]
},
"gsd": {
"metadata": {
"exploitCode": "unknown",
"remediation": "unknown",
"reportConfidence": "confirmed",
"type": "vulnerability"
},
"osvSchema": {
"aliases": [
"CVE-2018-5741"
],
"details": "To provide fine-grained controls over the ability to use Dynamic DNS (DDNS) to update records in a zone, BIND 9 provides a feature called update-policy. Various rules can be configured to limit the types of updates that can be performed by a client, depending on the key used when sending the update request. Unfortunately, some rule types were not initially documented, and when documentation for them was added to the Administrator Reference Manual (ARM) in change #3112, the language that was added to the ARM at that time incorrectly described the behavior of two rule types, krb5-subdomain and ms-subdomain. This incorrect documentation could mislead operators into believing that policies they had configured were more restrictive than they actually were. This affects BIND versions prior to BIND 9.11.5 and BIND 9.12.3.",
"id": "GSD-2018-5741",
"modified": "2023-12-13T01:22:40.445541Z",
"schema_version": "1.4.0"
}
},
"namespaces": {
"cve.org": {
"CVE_data_meta": {
"ASSIGNER": "security-officer@isc.org",
"DATE_PUBLIC": "2018-09-19T00:00:00.000Z",
"ID": "CVE-2018-5741",
"STATE": "PUBLIC",
"TITLE": "Update policies krb5-subdomain and ms-subdomain do not enforce controls promised in their documentation"
},
"affects": {
"vendor": {
"vendor_data": [
{
"product": {
"product_data": [
{
"product_name": "BIND 9",
"version": {
"version_data": [
{
"version_name": "BIND 9",
"version_value": "Versions prior to BIND 9.11.5 and BIND 9.12.3"
}
]
}
}
]
},
"vendor_name": "ISC"
}
]
}
},
"data_format": "MITRE",
"data_type": "CVE",
"data_version": "4.0",
"description": {
"description_data": [
{
"lang": "eng",
"value": "To provide fine-grained controls over the ability to use Dynamic DNS (DDNS) to update records in a zone, BIND 9 provides a feature called update-policy. Various rules can be configured to limit the types of updates that can be performed by a client, depending on the key used when sending the update request. Unfortunately, some rule types were not initially documented, and when documentation for them was added to the Administrator Reference Manual (ARM) in change #3112, the language that was added to the ARM at that time incorrectly described the behavior of two rule types, krb5-subdomain and ms-subdomain. This incorrect documentation could mislead operators into believing that policies they had configured were more restrictive than they actually were. This affects BIND versions prior to BIND 9.11.5 and BIND 9.12.3."
}
]
},
"impact": {
"cvss": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "NONE",
"baseScore": 6.5,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "NONE",
"integrityImpact": "HIGH",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N",
"version": "3.0"
}
},
"problemtype": {
"problemtype_data": [
{
"description": [
{
"lang": "eng",
"value": "The krb5-subdomain and ms-subdomain update policy rule types permit updates from any client authenticated with a valid Kerberos or Windows machine principal from the REALM specified in the identity field, to modify records in the zone at or below the name specified in the name field. The incorrect documentation, however, indicated that the policy would be restricted to names at or below the machine\u0027s name as encoded in the Windows or Kerberos principal.\n\nFor example, if named.conf contains the following configuration statement in the zone \"example.com\":\n\nzone example.com {\n ...\n update-policy {\n grant SUB.EXAMPLE.COM krb5-subdomain . ANY;\n };\n};\n\n...then a client possessing a valid Kerberos machine principal for host/machine.sub.example.com@SUB.EXAMPLE.COM would be allowed to update any record at or below \"example.com\", whereas the documentation indicated that updates would only be permitted at or below \"machine.sub.example.com\". In practice, the name of the machine encoded in the principal is not checked to ensure that it matches the records to be updated. The update policy for the zone, having established that the client possesses a valid machine principal from the SUB.EXAMPLE.COM realm, simply allows updates to all records within the zone \"example.com\".\n\nThe ms-subdomain rule type behaves similarly, but for Windows machine principals such as machine$@SUB.EXAMPLE.COM instead of Kerberos principals.\n\nThe krb5-subdomain and ms-subdomain rules are intended to limit updates to names below the name field (in this example, \".\", which covers the entire zone). Because of a separate bug in the named.conf parser, a name field below \".\" could not be configured in some releases.\n\nMaintenance releases of BIND released during or after October 2018 (9.11.5 or higher, 9.12.3 or higher) will address this configuration bug, as well as adding new krb5-selfsub and ms-selfsub rule types which more accurately implement the behavior that the ARM formerly attributed to krb5-subdomain and ms-subdomain."
}
]
}
]
},
"references": {
"reference_data": [
{
"name": "105379",
"refsource": "BID",
"url": "http://www.securityfocus.com/bid/105379"
},
{
"name": "1041674",
"refsource": "SECTRACK",
"url": "http://www.securitytracker.com/id/1041674"
},
{
"name": "https://kb.isc.org/docs/cve-2018-5741",
"refsource": "CONFIRM",
"url": "https://kb.isc.org/docs/cve-2018-5741"
},
{
"name": "GLSA-201903-13",
"refsource": "GENTOO",
"url": "https://security.gentoo.org/glsa/201903-13"
},
{
"name": "https://support.hpe.com/hpsc/doc/public/display?docLocale=en_US\u0026docId=emr_na-hpesbux03927en_us",
"refsource": "CONFIRM",
"url": "https://support.hpe.com/hpsc/doc/public/display?docLocale=en_US\u0026docId=emr_na-hpesbux03927en_us"
},
{
"name": "RHSA-2019:2057",
"refsource": "REDHAT",
"url": "https://access.redhat.com/errata/RHSA-2019:2057"
},
{
"name": "https://security.netapp.com/advisory/ntap-20190830-0001/",
"refsource": "CONFIRM",
"url": "https://security.netapp.com/advisory/ntap-20190830-0001/"
},
{
"name": "openSUSE-SU-2020:1699",
"refsource": "SUSE",
"url": "http://lists.opensuse.org/opensuse-security-announce/2020-10/msg00041.html"
},
{
"name": "openSUSE-SU-2020:1701",
"refsource": "SUSE",
"url": "http://lists.opensuse.org/opensuse-security-announce/2020-10/msg00044.html"
}
]
},
"solution": [
{
"lang": "eng",
"value": "At the time of public disclosure, ISC is not providing any code changing the behavior of the update-policy feature. While we believe that there are a few operators out there who are relying on the strictest interpretation permitted by the erroneous documentation, we have to balance that against changing the behavior of features in stable branches of BIND, including the 9.11 branch which is meant to be a feature-complete Extended Support Version of BIND 9. As a compromise between these conflicting priorities, we have decided that our best course of action is to disclose the error but leave the existing behavior of the krb5-subdomain and ms-subdomain policies as they are (while correcting the erroneous documentation).\n\nIn maintenance releases issued during or after October 2018, the name field for ms-subdomain and krb5-subdomain will be corrected so that names lower than \".\" can be configured, and two new rule types will be added, krb5-selfsub and ms-selfsub, analogous to the existing selfsub rule type, which implement the behavior that was formerly described in the documentation for krb5-subdomain and ms-subdomain: restricting updates to names at or below the machine name encoded in the client\u0027s Windows or Kerberos principal. \n"
}
],
"source": {
"discovery": "EXTERNAL"
},
"work_around": [
{
"lang": "eng",
"value": "To limit updates to a subset of a zone -- for example, \"sub.example.com\" -- create a new \"sub.example.com\" child zone beneath \"example.com\", and set the desired update-policy in the child zone rather than the parent."
}
]
},
"nvd.nist.gov": {
"configurations": {
"CVE_data_version": "4.0",
"nodes": [
{
"children": [],
"cpe_match": [
{
"cpe23Uri": "cpe:2.3:a:isc:bind:*:*:*:*:*:*:*:*",
"cpe_name": [],
"versionEndExcluding": "9.11.5",
"vulnerable": true
},
{
"cpe23Uri": "cpe:2.3:a:isc:bind:*:*:*:*:*:*:*:*",
"cpe_name": [],
"versionEndExcluding": "9.12.3",
"versionStartIncluding": "9.12.0",
"vulnerable": true
}
],
"operator": "OR"
}
]
},
"cve": {
"CVE_data_meta": {
"ASSIGNER": "security-officer@isc.org",
"ID": "CVE-2018-5741"
},
"data_format": "MITRE",
"data_type": "CVE",
"data_version": "4.0",
"description": {
"description_data": [
{
"lang": "en",
"value": "To provide fine-grained controls over the ability to use Dynamic DNS (DDNS) to update records in a zone, BIND 9 provides a feature called update-policy. Various rules can be configured to limit the types of updates that can be performed by a client, depending on the key used when sending the update request. Unfortunately, some rule types were not initially documented, and when documentation for them was added to the Administrator Reference Manual (ARM) in change #3112, the language that was added to the ARM at that time incorrectly described the behavior of two rule types, krb5-subdomain and ms-subdomain. This incorrect documentation could mislead operators into believing that policies they had configured were more restrictive than they actually were. This affects BIND versions prior to BIND 9.11.5 and BIND 9.12.3."
}
]
},
"problemtype": {
"problemtype_data": [
{
"description": [
{
"lang": "en",
"value": "CWE-863"
}
]
}
]
},
"references": {
"reference_data": [
{
"name": "https://kb.isc.org/docs/cve-2018-5741",
"refsource": "CONFIRM",
"tags": [
"Vendor Advisory"
],
"url": "https://kb.isc.org/docs/cve-2018-5741"
},
{
"name": "1041674",
"refsource": "SECTRACK",
"tags": [
"Third Party Advisory",
"VDB Entry"
],
"url": "http://www.securitytracker.com/id/1041674"
},
{
"name": "105379",
"refsource": "BID",
"tags": [
"Third Party Advisory",
"VDB Entry"
],
"url": "http://www.securityfocus.com/bid/105379"
},
{
"name": "GLSA-201903-13",
"refsource": "GENTOO",
"tags": [
"Third Party Advisory"
],
"url": "https://security.gentoo.org/glsa/201903-13"
},
{
"name": "https://support.hpe.com/hpsc/doc/public/display?docLocale=en_US\u0026docId=emr_na-hpesbux03927en_us",
"refsource": "CONFIRM",
"tags": [],
"url": "https://support.hpe.com/hpsc/doc/public/display?docLocale=en_US\u0026docId=emr_na-hpesbux03927en_us"
},
{
"name": "RHSA-2019:2057",
"refsource": "REDHAT",
"tags": [],
"url": "https://access.redhat.com/errata/RHSA-2019:2057"
},
{
"name": "https://security.netapp.com/advisory/ntap-20190830-0001/",
"refsource": "CONFIRM",
"tags": [],
"url": "https://security.netapp.com/advisory/ntap-20190830-0001/"
},
{
"name": "openSUSE-SU-2020:1699",
"refsource": "SUSE",
"tags": [],
"url": "http://lists.opensuse.org/opensuse-security-announce/2020-10/msg00041.html"
},
{
"name": "openSUSE-SU-2020:1701",
"refsource": "SUSE",
"tags": [],
"url": "http://lists.opensuse.org/opensuse-security-announce/2020-10/msg00044.html"
}
]
}
},
"impact": {
"baseMetricV2": {
"acInsufInfo": false,
"cvssV2": {
"accessComplexity": "LOW",
"accessVector": "NETWORK",
"authentication": "SINGLE",
"availabilityImpact": "NONE",
"baseScore": 4.0,
"confidentialityImpact": "NONE",
"integrityImpact": "PARTIAL",
"vectorString": "AV:N/AC:L/Au:S/C:N/I:P/A:N",
"version": "2.0"
},
"exploitabilityScore": 8.0,
"impactScore": 2.9,
"obtainAllPrivilege": false,
"obtainOtherPrivilege": false,
"obtainUserPrivilege": false,
"severity": "MEDIUM",
"userInteractionRequired": false
},
"baseMetricV3": {
"cvssV3": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "NONE",
"baseScore": 6.5,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "NONE",
"integrityImpact": "HIGH",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N",
"version": "3.0"
},
"exploitabilityScore": 2.8,
"impactScore": 3.6
}
},
"lastModifiedDate": "2020-10-20T12:15Z",
"publishedDate": "2019-01-16T20: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.