CVE-2013-4854: FAQ and Supplemental Information
  • 06 Dec 2018
  • 3 Minutes to read
  • Contributors
  • Dark
    Light
  • PDF

CVE-2013-4854: FAQ and Supplemental Information

  • Dark
    Light
  • PDF

Article Summary

About This Document

For up-to-date information on this vulnerability, patches, and other operational information, please see the official vulnerability announcement. This article is intended to supplement the information in that announcement and will be updated as needed to further describe the operational impact of this vulnerability.

Am I vulnerable?

  • The bug causing this problem was inadvertently introduced in BIND 9.7 when we added support for RFC 5011 - so we are confident that this vulnerability only impacts 9.7, 9.8, and 9.9 major versions.
  • Any server that receives client queries is vulnerable. The defect is in the code that prepares a logging message during processing of the query.
  • Both authoritative and recursive servers are at risk.
  • Administrators of recursive-only servers with trusted clients could still be impacted if those clients are permitted to browse Internet websites.

Can a server be protected by introducing tighter Access Controls?

  • Access Controls do not provide any protection. A query will always be processed, even if the response to the client would be REFUSED or the query ignored. The vulnerability is in the preparation of the log message.

Are the recent release candidates of BIND 9.8 and 9.9 also vulnerable?

  • ISC has released patched production versions of BIND (9.8.5-P2, 9.9.3-P2, and 9.9.3-S1-P1) as a solution for production environments. In parallel we have BIND 9.8.6, 9.9.4, and 9.9.4-S1 under development, and as part of the release cycle we recently released 9.8.6rc1, 9.9.4rc1, and 9.9.4-S1rc1. These versions are vulnerable, but we do not recommend or expect that they will be used on production servers.
  • The final production versions of BIND 9.8.6, 9.9.4, and 9.9.4-S1 will carry the fix for this problem.

Any further release candidates that replace 9.8.6rc1, 9.9.4rc1, and 9.9.4S1rc1 would also carry the fix. We do not yet know if they will be needed during this development cycle.

Will there be a patch for BIND 9.7?

  • We do not plan to release a patch for BIND 9.7.

What are versions 9.9.3-S1, 9.9.3-S1-P1, and 9.9.4-S1?

  • These are subscription-only versions of BIND providing additional features. If you'd like more information on our product support or about our Subscription versions of BIND, please visit https://www.isc.org/support.

My server crashed. Did it have anything to do with this bug?

  • Exploitation of this vulnerability will result in BIND terminating after logging a "REQUIRE" failure in rdata.c.
  • The exact line number will vary according to your version, but the error text will read:  "REQUIRE(region->length >= 4) failed"

Are applications or utilities vulnerable that have been built using libraries from the affected versions of BIND?

  • This vulnerability could impact applications (such as dig) which, when built, are directly using the libraries distributed with BIND - we recommend that these are also updated (in most cases this will happen during the build of the replacement BIND package when the new binaries are installed).
  • Third-party applications or utilities (which may include resolver clients) that have been built directly using the libraries distributed with affected BIND source distributions might crash with assertion failures triggered in the same fashion. These applications and utilities should be rebuilt using libraries from a version of BIND that includes the fix.

Are clients using the resolver libraries (libbind) vulnerable to this problem?

  • Most clients are using resolver libraries that are specific to their OS vendor/distributor - ISC cannot provide any guarantees that responses parsed by third-party resolver libraries would not cause them to crash, although it is very unlikely that they would experience any issues from the specific case being addressed by this advisory.
  • ISC's libbind is not vulnerable to this issue (it does not need to be aware of the RFC 5011 rdata types, so has never been updated to recognize them).