cnvd - cnvd-2018-19398

cnvd-2018-19398

Vulnerability from cnvd

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

Modified

2024-09-17 02:26

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.

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.

References

▼	URL	Tags
	http://www.securityfocus.com/bid/105379	vdb-entry, x_refsource_BID
	http://www.securitytracker.com/id/1041674	vdb-entry, x_refsource_SECTRACK
	https://kb.isc.org/docs/cve-2018-5741	x_refsource_CONFIRM
	https://security.gentoo.org/glsa/201903-13	vendor-advisory, x_refsource_GENTOO
	https://support.hpe.com/hpsc/doc/public/display?docLocale=en_US&docId=emr_na-hpesbux03927en_us	x_refsource_CONFIRM
	https://access.redhat.com/errata/RHSA-2019:2057	vendor-advisory, x_refsource_REDHAT
	https://security.netapp.com/advisory/ntap-20190830-0001/	x_refsource_CONFIRM
	http://lists.opensuse.org/opensuse-security-announce/2020-10/msg00041.html	vendor-advisory, x_refsource_SUSE
	http://lists.opensuse.org/opensuse-security-announce/2020-10/msg00044.html	vendor-advisory, x_refsource_SUSE

Impacted products

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

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",
      "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",
        "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:00Z",
    "dateReserved": "2018-01-17T00:00:00",
    "dateUpdated": "2024-09-17T02:26:39.095Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.1"
}

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.

Action not permitted