This is an update to security information we provided recently.
It clarifies some language in the advisory for CVE-2017-3143.
If you have already applied patches to correct this vulnerability
you do not need to worry about the rest of this message; it is
intended primarily for operators who are unsure about whether or
not they are vulnerable to CVE-2017-3143.  You can also disregard
this message if you do not make use of the "update-policy local;"
statement in your server configuration.

For those who *do* use "update-policy local;":  after publication
of our advisory for CVE-2017-3143 we received some requests to make
it clearer how it relates to the local update policy.  Having reviewed
the advisory text, we agree with those who asked us to issue an updated
version to better explain this issue.

Up through revision 2.0 of the text (Public release, 29 June 2017)
the advisory contained this language:

   Administrators who have made use of named.conf option "update-policy
   local;" should refer to the Administrator Reference Manual (ARM)
   for details of the automatic update policy that will be established
   and to assess whether or not this conveys any additional risk
   to their server.  (Note that this option is not enabled by

While true, and while drawing some attention to "update-policy local;"
we believe now we should have explained more clearly how CVE-2017-3143
relates to this feature.

In BIND there are two ways of enabling dynamic updates.  You can
use the "allow-update" statement, explicitly providing qualifying
conditions such as IP ACLs and TSIG key requirements, or you can
use the "update-policy" statement, which is intended to implement
some common patterns as preconfigured rule sets you can select.

One of these is the "local" update policy, intended to enable easy
configuration of updates from localhost using the "nsupdate -l"
command, and turned on by using the statement "update-policy local;"
in named.conf.

If you have selected the local update policy for a zone, updates
to the zone will be permitted for the key "local-ddns".  Here is
a description from section 6.2 of the BIND Administrator Reference

   There is a pre-defined update-policy rule which can be switched
   on with the command update-policy local; . Switching on this
   rule in a zone causes named to generate a TSIG session key and
   place it in a file, and to allow that key to update the zone.
   (By default, the file is /var/run/named/session.key, the key
   name is "local-ddns" and the key algorithm is HMAC-SHA256, but
   these values are configurable with the session-keyfile,
   session-keyname and session-keyalg options, respectively).

   A client running on the local system, and with appropriate
   permissions, may read that file and use the key to sign update
   requests.  The zone’s update policy will be set to allow that
   key to change any record within the zone. Assuming the key name
   is "local-ddns", this policy is equivalent to:

      update-policy { grant local-ddns zonesub any; };

Unfortunately, the update-policy statement only examines the signer
of a message; the source address is not relevant.  Ordinarily this
isn't a significant issue because the key is still required for
authentication, however CVE-2017-3143 permits an update message to
be improperly accepted if the key name and algorithm are known.
In conjunction with the use of a known key name ("local-ddns")
and default algorithm, it is therefore very easy to inadvertently
expose an unpatched server to CVE-2017-3143 by using "update-policy

The best remedy, in our opinion, is to upgrade to a patched version
of BIND which is not vulnerable to CVE-2017-3143.  However, if this
is not an option operators can replace the update policy statement
with this allow-update alternative:

   allow-update { !{ !localhost; }; key local-ddns; };

which properly restricts permission to updates originating from
localhost with the key local-ddns.

Michael McNally
ISC Security Officer
bind-announce mailing list

Reply via email to