Package: libbind9-160
Version: 1:9.11.4.P2+dfsg-1
Severity: grave
Tags: security upstream patch
Forwarded: security-offi...@isc.org
Control: found -1 1:9.11.4.P1+dfsg-1
Control: found -1 1:9.11.4+dfsg-4
Hi,
I discovered the following security bug in bind9 a few weeks ago, and
responsibly disclosed it to the ISC security officer. Unfortunately, until
today they did not acknowledge it is a security issue - in contrast, they
proved that they do not fully understand the issue, and now have added a new
feature in the 9.11.4.P2 release which wrongly addresses this security
issue.
The issue is with DDNS update policies using Kerberos, namely the
krb5-subdomain and ms-subdomain update policies for TKEY-GSSAPI. The
documentation states, and has always stated, the following:
krb5-self
-
This rule takes a Kerberos machine principal (host/machine@REALM) for
machine in REALM and and converts it machine.realm allowing the machine to
update machine.realm. The REALM to be matched is specified in the identity
field. The name field should be set to "."
krb5-subdomain
--
This rule takes a Kerberos machine principal (host/machine@REALM) for
machine in REALM and converts it to machine.realm allowing the machine to
update subdomains of machine.realm. The REALM to be matched is specified in
the identity field. The name field should be set to "."
https://ftp.isc.org/isc/bind9/9.11.4-P1/doc/arm/Bv9ARM.ch06.html#dynamic_update_policies
(I am referring to both krb5-* and ms-* when saying krb5-* in the
following.)
Now the issue is the following (at least in all revisions of bind 9.10 and
9.11, *including the recently released 9.11.4.P1 and .P2*:
krb5-self works a documented, and allows any client showing a valid Kerberos
ticket for machine.realm to update exactly machine.realm.
However, krb5-subdomain is missing the documented check completely - *it
allows updating all records*. To be more precise, it checks the name of the
record to be updated against the name field, instead of, as documented,
against the machine name from the Kerberos identity.
If a BIND TKEY update policy is configured as described in the manual, with
the administrator intending to allow machines to update records below their
own hostname, they are indeed granting full access to the whole zonem
because the documented Kerberos name check is missing.
The ISC security officer claims the following:
The documented update policy was never intended to work like documented.
It was intended to work like th ecode does, only checking against the
configured name field instead of the Kerberos machine name.
This is not a security issue - it is a documentation bug.
I have raised concerns about these views with the ISC because it has some
implications that I will not believe to be correct:
There already is a check called subdomai n(without krb5-) that allows
updating subdomains of the configured name. It can also take a Kerberos
principal name as TKEY identity - in that case it allows updating the
subdomain given in the name field if a client shows a valid Kerberos
ticket for the principal in the identity field. This is what the ISC
claims to be the intention of krb5-subdomain - I do, however, doubt that
the person adding the krb5-subdomain check intended to add a new check
that does the same as the existing subdomain check.
(I also doubt that the person intended to duplicate an existing check,
then accidentally added documentation stating the contrary.)
The code for krb5-subdomain *does* go through all the hassle to extract
the machine name from the given Kerberos identity - it then ignores the
result and always returns TRUE instead of checking the record to be
updated against the machine name it just got hold of with so much work.
I do doubt that the person writing the original code, in addition to
the above, intentionally added this code handling a Kerberos identity,
then always returning TRUE, resulting in the check to do the same as the
normal subdomain check - only with 100 lines of string manipulation
resulting in a no-op wrapped around it.
Even after explaining all this to the ISC, they decided to not fix these
checks to do what they are documented (and obviously intended) to do.
Instead, in 9.11.4.P1, they added *new* checks called krb5-subself and
ms-subself that do what krb5-subdomain and ms-subdomain were intended to do,
and sold this as a new feature (they also did not mention my research and
patching efforts doing so, they just told the world they added a cool new
feature - THANK YOU !). The broken -subdomain checks were kept as they
are, including the broken documentation.
Even if the ISC intends to keep the broken checks (which, again, are
duplicates of a more simple check, with tons of string manipulation code
wrapped around), I still consider this a serious security issue because with
the checks not doing what the documentation says for many
