CVE-2018-5741: Update policies krb5-subdomain and ms-subdomain do not enforce controls promised in their documentation

[Michael McNally]

CVE:                 CVE-2018-5741
Document Version:    1.0
Posting date:        19 September 2018
Program Impacted:    BIND
Versions affected:

   The behavior described is present in all versions of BIND 9 which
   contain the krb5-subdomain and ms-subdomain update policies prior
   to our upcoming maintenance releases, BIND 9.11.5 and 9.12.3.
   However, the misleading documentation is not present in all
   versions.

Severity:            Medium
Exploitable:         Remotely, but only by an attacker with credentials
                     to modify other records on the server

Description:

   In order to provide fine-grained controls over the ability to
   use Dynamic DNS (DDNS) to update records in a zone, BIND 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.

Impact:

   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
   Kebreros 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 at 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 of 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.

   Upcoming maintenance releases 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.

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

For more information on the Common Vulnerability Scoring System and
to obtain your specific environmental score please visit:
https://www.first.org/cvss/calculator/3.0#CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N

Workarounds:

   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.

Active exploits:

   No known active exploits but the reporter has also disclosed the
   issue to a public bug tracker for another open-source project.

Solution:

   At the present time, 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.
   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.

   In upcoming maintenance releases, 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's Windows or Kerberos principal.  These new
   update-policy options will debut in the next set of maintenance
   releases scheduled for the BIND 9.11 and 9.12 branches (as well
   as the BIND 9.13 development branch) and should be available to
   users in October 2018.

   +  BIND 9.11.5
   +  BIND 9.12.3

Acknowledgements:

   This issue was reported to us by Dominik George.

Document Revision History:

   1.0 Public Disclosure 19 September 2018

Related Documents:

   See our BIND9 Security Vulnerability Matrix at
   https://kb.isc.org/article/AA-00913 for a complete listing of
   Security Vulnerabilities and versions affected.

If you'd like more information on ISC Subscription Support and
Advance Security Notifications, please visit http://www.isc.org/support/.

Do you still have questions?  Questions regarding this advisory
should go to security-officer at isc.org.  To report a new issue,
please encrypt your message using security-officer at isc.org's PGP
key which can be found here:
   https://www.isc.org/downloads/software-support-policy/openpgp-key/.
If you are unable to use encrypted email, you may also report new
issues at: https://www.isc.org/community/report-bug/.

Note:

   ISC patches only currently supported versions. When possible we
   indicate EOL versions affected.  (For current information on
   which versions are actively supported, please see
   http://www.isc.org/downloads/).

ISC Security Vulnerability Disclosure Policy:

   Details of our current security advisory policy and practice can
   be found here: https://kb.isc.org/article/AA-00861

Legal Disclaimer:

   Internet Systems Consortium (ISC) is providing this notice on
   an "AS IS" basis. No warranty or guarantee of any kind is expressed
   in this notice and none should be implied. ISC expressly excludes
   and disclaims any warranties regarding this notice or materials
   referred to in this notice, including, without limitation, any
   implied warranty of merchantability, fitness for a particular
   purpose, absence of hidden defects, or of non-infringement. Your
   use or reliance on this notice or materials referred to in this
   notice is at your own risk. ISC may change this notice at any
   time.  A stand-alone copy or paraphrase of the text of this
   document that omits the document URL is an uncontrolled copy.
   Uncontrolled copies may lack important information, be out of
   date, or contain factual errors.

(c) 2001-2018 Internet Systems Consortium