ISC BIND TKEY Query Out-Of-Bounds Read Information Disclosure Vulnerability

Brian Conry bconry at
Fri Jun 25 21:30:39 UTC 2021

On 6/24/21 4:01 PM, Petr Menšík wrote:
> I have received this issue bug too, without any obvious link to CVE
> number assigned. It would be nice if ISC could confirm this is about the
> same issue as mentioned CVE, just reported from different party. It just
> claims it was fixed in 9.16.15, from where I guessed it should be this
> change.
> Guessing is not comfortable way to fix security vulnerabilities though.
> *CVSS Score *is different. Could it be original report, which was proved
> to be worse later? Is it irelevant since original code containing that
> issue is no longer shipped?
> **

Without additional context from what you're seeing, I can't be certain
whether you are discussing CVE-2020-8625 or CVE-2021-25216, or if you're
even talking about the same one.

So I'm just going to try to cover all the bases.  :)

I do have a bit more identifying information about the two, though
(which can be found in our gitlab issues[1][2]).  CVE-2020-8625 is also
known as ZDI-CAN-12302 and CVE-2021-25216 is also known as ZDI-CAN-13347.

We did not completely agree with the scoring given on the ZDI-CAN
issues, and note also that the scoring for CVE-2021-25216 depends on
whether you're building on a 32-bit or 64-bit architecture.  Other
scorings may be defensible as well.

The bug reported to us as ZDI-CAN-12302, and which became CVE-2020-8625,
was identified year earlier in mod_auth_kerb as CVE-2006-5989.  In
mod_auth_kerb it was reported as being merely a denial-of-service issue,
but it was reported to us as being at least a theoretical code execution
vulnerability.  Clearly that results in different scores, not to mention
the use of different CVSS versions in use.

For those wondering, CVE-2006-5989 was announced after we
forked/borrowed the code, though still before our first official release
with it.  Obviously we weren't keeping an eye on the upstream source for

I agree that guessing isn't the best way to fix security
vulnerabilities.  Fortunately, though, the recommendation is the same
for both of these, as well as any other issue that may have been
reported against ISC's SPNEGO code.  Implement change 5609, mentioned by
Tony, removing our SPNEGO code completely.

If you don't want to make that change to the codebase, at least
configure/build with --disable-isc-spnego, as also mentioned by Tony.
This is listed as an official work-around for both CVE-2020-8625 and

Brian Conry

[1] -
[2] -

More information about the bind-workers mailing list