Vulnerability-Lookup

CNVD-2018-19398

Vulnerability from cnvd - Published: 2018-09-20

Title

ISC BIND 9 krb5-subdomain and ms-subdomain更新策略漏洞

Description

ISC BIND是美国Internet Systems Consortium（ISC）公司所维护的一套实现了DNS协议的开源软件。为了对使用动态DNS（DDNS）更新区域中的记录的能力提供细粒度控制，BIND提供了一个名为update-policy的功能。可以配置各种规则来限制客户端可以执行的更新类型，具体取决于发送更新请求时使用的密钥。不幸的是，有些规则类型最初没有记录，当它们的文档在变更＃3112中添加到管理员参考手册（ARM）时，当时添加到ARM的语言错误地描述了两种规则类型的行为，krb5 -subdomain和ms-subdomain。这种不正确的文档可能会误导操作员相信他们配置的策略比实际更严格。

Severity

中

Formal description

目前没有详细的解决方案提供： https://www.isc.org/downloads/bind/

Reference

https://kb.isc.org/docs/cve-2018-5741

Impacted products

Name
ISC BIND 9

Show details on source website

JSON

To clipboard

{
  "cves": {
    "cve": {
      "cveNumber": "CVE-2018-5741"
    }
  },
  "description": "ISC BIND\u662f\u7f8e\u56fdInternet Systems Consortium\uff08ISC\uff09\u516c\u53f8\u6240\u7ef4\u62a4\u7684\u4e00\u5957\u5b9e\u73b0\u4e86DNS\u534f\u8bae\u7684\u5f00\u6e90\u8f6f\u4ef6\u3002 \r\n\r\n\u4e3a\u4e86\u5bf9\u4f7f\u7528\u52a8\u6001DNS\uff08DDNS\uff09\u66f4\u65b0\u533a\u57df\u4e2d\u7684\u8bb0\u5f55\u7684\u80fd\u529b\u63d0\u4f9b\u7ec6\u7c92\u5ea6\u63a7\u5236\uff0cBIND\u63d0\u4f9b\u4e86\u4e00\u4e2a\u540d\u4e3aupdate-policy\u7684\u529f\u80fd\u3002\u53ef\u4ee5\u914d\u7f6e\u5404\u79cd\u89c4\u5219\u6765\u9650\u5236\u5ba2\u6237\u7aef\u53ef\u4ee5\u6267\u884c\u7684\u66f4\u65b0\u7c7b\u578b\uff0c\u5177\u4f53\u53d6\u51b3\u4e8e\u53d1\u9001\u66f4\u65b0\u8bf7\u6c42\u65f6\u4f7f\u7528\u7684\u5bc6\u94a5\u3002\u4e0d\u5e78\u7684\u662f\uff0c\u6709\u4e9b\u89c4\u5219\u7c7b\u578b\u6700\u521d\u6ca1\u6709\u8bb0\u5f55\uff0c\u5f53\u5b83\u4eec\u7684\u6587\u6863\u5728\u53d8\u66f4\uff033112\u4e2d\u6dfb\u52a0\u5230\u7ba1\u7406\u5458\u53c2\u8003\u624b\u518c\uff08ARM\uff09\u65f6\uff0c\u5f53\u65f6\u6dfb\u52a0\u5230ARM\u7684\u8bed\u8a00\u9519\u8bef\u5730\u63cf\u8ff0\u4e86\u4e24\u79cd\u89c4\u5219\u7c7b\u578b\u7684\u884c\u4e3a\uff0ckrb5 -subdomain\u548cms-subdomain\u3002\u8fd9\u79cd\u4e0d\u6b63\u786e\u7684\u6587\u6863\u53ef\u80fd\u4f1a\u8bef\u5bfc\u64cd\u4f5c\u5458\u76f8\u4fe1\u4ed6\u4eec\u914d\u7f6e\u7684\u7b56\u7565\u6bd4\u5b9e\u9645\u66f4\u4e25\u683c\u3002",
  "discovererName": "Dominik George",
  "formalWay": "\u76ee\u524d\u6ca1\u6709\u8be6\u7ec6\u7684\u89e3\u51b3\u65b9\u6848\u63d0\u4f9b\uff1a\r\nhttps://www.isc.org/downloads/bind/",
  "isEvent": "\u901a\u7528\u8f6f\u786c\u4ef6\u6f0f\u6d1e",
  "number": "CNVD-2018-19398",
  "openTime": "2018-09-20",
  "products": {
    "product": "ISC BIND 9"
  },
  "referenceLink": "https://kb.isc.org/docs/cve-2018-5741",
  "serverity": "\u4e2d",
  "submitTime": "2018-09-20",
  "title": "ISC BIND 9 krb5-subdomain and ms-subdomain\u66f4\u65b0\u7b56\u7565\u6f0f\u6d1e"
}

CVE-2018-5741 (GCVE-0-2018-5741)

Vulnerability from cvelistv5 – Published: 2019-01-16 20:00 – Updated: 2024-09-17 02:26

Title

Update policies krb5-subdomain and ms-subdomain do not enforce controls promised in their documentation

Summary

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.

Severity

6.5 (Medium)


                        
                          CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N

CWE

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's name as encoded in the Windows or Kerberos principal. For example, if named.conf contains the following configuration statement in the zone "example.com": zone example.com { ... update-policy { grant SUB.EXAMPLE.COM krb5-subdomain . ANY; }; }; ...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". The ms-subdomain rule type behaves similarly, but for Windows machine principals such as machine$@SUB.EXAMPLE.COM instead of Kerberos principals. The 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. Maintenance 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.

Assigner

isc CNA under the mitre root

CNA scorecard A 95/100 over 29 records in the last 180 days details

References

9 references

URL	Tags
http://www.securityfocus.com/bid/105379	vdb-entryx_refsource_BID
http://www.securitytracker.com/id/1041674	vdb-entryx_refsource_SECTRACK
https://kb.isc.org/docs/cve-2018-5741	x_refsource_CONFIRM
https://security.gentoo.org/glsa/201903-13	vendor-advisoryx_refsource_GENTOO
https://support.hpe.com/hpsc/doc/public/display?d…	x_refsource_CONFIRM
https://access.redhat.com/errata/RHSA-2019:2057	vendor-advisoryx_refsource_REDHAT
https://security.netapp.com/advisory/ntap-2019083…	x_refsource_CONFIRM
http://lists.opensuse.org/opensuse-security-annou…	vendor-advisoryx_refsource_SUSE
http://lists.opensuse.org/opensuse-security-annou…	vendor-advisoryx_refsource_SUSE

Impacted products

1 product

Vendor	Product	Version
ISC	BIND 9	Affected: BIND 9 Versions prior to BIND 9.11.5 and BIND 9.12.3

Date Public

2018-09-19 00:00

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "adp": [
      {
        "providerMetadata": {
          "dateUpdated": "2024-08-05T05:40:51.195Z",
          "orgId": "af854a3a-2127-422b-91ae-364da2661108",
          "shortName": "CVE"
        },
        "references": [
          {
            "name": "105379",
            "tags": [
              "vdb-entry",
              "x_refsource_BID",
              "x_transferred"
            ],
            "url": "http://www.securityfocus.com/bid/105379"
          },
          {
            "name": "1041674",
            "tags": [
              "vdb-entry",
              "x_refsource_SECTRACK",
              "x_transferred"
            ],
            "url": "http://www.securitytracker.com/id/1041674"
          },
          {
            "tags": [
              "x_refsource_CONFIRM",
              "x_transferred"
            ],
            "url": "https://kb.isc.org/docs/cve-2018-5741"
          },
          {
            "name": "GLSA-201903-13",
            "tags": [
              "vendor-advisory",
              "x_refsource_GENTOO",
              "x_transferred"
            ],
            "url": "https://security.gentoo.org/glsa/201903-13"
          },
          {
            "tags": [
              "x_refsource_CONFIRM",
              "x_transferred"
            ],
            "url": "https://support.hpe.com/hpsc/doc/public/display?docLocale=en_US\u0026docId=emr_na-hpesbux03927en_us"
          },
          {
            "name": "RHSA-2019:2057",
            "tags": [
              "vendor-advisory",
              "x_refsource_REDHAT",
              "x_transferred"
            ],
            "url": "https://access.redhat.com/errata/RHSA-2019:2057"
          },
          {
            "tags": [
              "x_refsource_CONFIRM",
              "x_transferred"
            ],
            "url": "https://security.netapp.com/advisory/ntap-20190830-0001/"
          },
          {
            "name": "openSUSE-SU-2020:1699",
            "tags": [
              "vendor-advisory",
              "x_refsource_SUSE",
              "x_transferred"
            ],
            "url": "http://lists.opensuse.org/opensuse-security-announce/2020-10/msg00041.html"
          },
          {
            "name": "openSUSE-SU-2020:1701",
            "tags": [
              "vendor-advisory",
              "x_refsource_SUSE",
              "x_transferred"
            ],
            "url": "http://lists.opensuse.org/opensuse-security-announce/2020-10/msg00044.html"
          }
        ],
        "title": "CVE Program Container"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "BIND 9",
          "vendor": "ISC",
          "versions": [
            {
              "status": "affected",
              "version": "BIND 9 Versions prior to BIND 9.11.5 and BIND 9.12.3"
            }
          ]
        }
      ],
      "datePublic": "2018-09-19T00:00:00.000Z",
      "descriptions": [
        {
          "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."
        }
      ],
      "metrics": [
        {
          "cvssV3_0": {
            "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"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "description": "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.",
              "lang": "en",
              "type": "text"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2020-10-20T11:06:45.000Z",
        "orgId": "404fd4d2-a609-4245-b543-2c944a302a22",
        "shortName": "isc"
      },
      "references": [
        {
          "name": "105379",
          "tags": [
            "vdb-entry",
            "x_refsource_BID"
          ],
          "url": "http://www.securityfocus.com/bid/105379"
        },
        {
          "name": "1041674",
          "tags": [
            "vdb-entry",
            "x_refsource_SECTRACK"
          ],
          "url": "http://www.securitytracker.com/id/1041674"
        },
        {
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://kb.isc.org/docs/cve-2018-5741"
        },
        {
          "name": "GLSA-201903-13",
          "tags": [
            "vendor-advisory",
            "x_refsource_GENTOO"
          ],
          "url": "https://security.gentoo.org/glsa/201903-13"
        },
        {
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://support.hpe.com/hpsc/doc/public/display?docLocale=en_US\u0026docId=emr_na-hpesbux03927en_us"
        },
        {
          "name": "RHSA-2019:2057",
          "tags": [
            "vendor-advisory",
            "x_refsource_REDHAT"
          ],
          "url": "https://access.redhat.com/errata/RHSA-2019:2057"
        },
        {
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://security.netapp.com/advisory/ntap-20190830-0001/"
        },
        {
          "name": "openSUSE-SU-2020:1699",
          "tags": [
            "vendor-advisory",
            "x_refsource_SUSE"
          ],
          "url": "http://lists.opensuse.org/opensuse-security-announce/2020-10/msg00041.html"
        },
        {
          "name": "openSUSE-SU-2020:1701",
          "tags": [
            "vendor-advisory",
            "x_refsource_SUSE"
          ],
          "url": "http://lists.opensuse.org/opensuse-security-announce/2020-10/msg00044.html"
        }
      ],
      "solutions": [
        {
          "lang": "en",
          "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."
        }
      ],
      "source": {
        "discovery": "EXTERNAL"
      },
      "title": "Update policies krb5-subdomain and ms-subdomain do not enforce controls promised in their documentation",
      "workarounds": [
        {
          "lang": "en",
          "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."
        }
      ],
      "x_legacyV4Record": {
        "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": "en",
            "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."
          }
        ],
        "source": {
          "discovery": "EXTERNAL"
        },
        "work_around": [
          {
            "lang": "en",
            "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."
          }
        ]
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "404fd4d2-a609-4245-b543-2c944a302a22",
    "assignerShortName": "isc",
    "cveId": "CVE-2018-5741",
    "datePublished": "2019-01-16T20:00:00.000Z",
    "dateReserved": "2018-01-17T00:00:00.000Z",
    "dateUpdated": "2024-09-17T02:26:39.095Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.1"
}

Sightings

Author	Source	Type	Date	Other

Nomenclature

Seen: The vulnerability was mentioned, discussed, or observed by the user.
Confirmed: The vulnerability has been validated from an analyst's perspective.
Published Proof of Concept: A public proof of concept is available for this vulnerability.
Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
Not confirmed: The user expressed doubt about the validity of the vulnerability.
Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Vulnerability timeline

Sightings and recorded dates, grouped by day · UTC

Order JSON

Publication & reservation Sightings KEV catalogs Other timestamps

Loading timeline…

The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base model, served locally by ML-Gateway. They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.

Action not permitted