CVE-2013-2266: FAQ and Supplemental Information
  • 06 Dec 2018
  • 5 Minutes to read
  • Contributors
  • Dark
  • PDF

CVE-2013-2266: FAQ and Supplemental Information

  • Dark
  • 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 problem is encountered when a program compiled to link to libdns receives a maliciously-constructed regular expression via any of several delivery methods.

  • Affected versions of BIND 9 are:  All versions of BIND 9.7; BIND 9.8.0 -> 9.8.5b1 (inclusive); BIND 9.9.0 -> 9.9.3b1 (inclusive).
  • The function containing the exploitable defect was added to BIND 9 in BIND 9.7.0; therefore, versions of BIND 9 prior to BIND 9.7.0 (including BIND 9.6-ESV and all lower-numbered versions) are not vulnerable to this defect.
  • The function containing the exploitable defect depends on system libraries and header files that are present only on "Unix-like" operating systems; if the libraries don't exist on a platform the function is compiled out. Consequently, Windows versions of BIND 9 are not affected by this vulnerability.
  • Unless they are prevented by firewall from having any communications with your server, you should assume that an attacker using this exploit can attack any BIND 9 nameserver (running on a Unix-like OS) that is executing one of the specified vulnerable versions.
  • Relying on firewalls for protection is not recommended - potential attackers might well find a way to reflect an attack via one of your clients if they can cause your client to make the right kind of request to your servers.
  • BIND 10 is a separate product from BIND 9 and uses a different code base. BIND 10 is not affected by this vulnerability. However, at the time of this advisory, BIND 10 is not "feature complete," and depending on your deployment needs, may not be a suitable replacement for BIND 9.
  • This vulnerability can potentially affect other programs built with libdns. It has been demonstrated in the utility program dig and other utility programs shipped as part of the BIND package. Even if you are not running a vulnerable named server, you should still patch utility programs shipped as part of the BIND distribution if they are present on your system.
  • This vulnerability can affect users of DHCP 4.2 using Dynamic DNS (DDNS). See CVE-2013-2494: A Vulnerability in libdns Could Cause Excessive Memory Use in ISC DHCP 4.2.

What effect will compiling without regular expression support have on my server?

  • The functionality that is removed by deactivation is a pre-parsing of the RDATA of certain record types that can contain regular expressions. BIND will still function normally when handling these records - i.e. loading or dynamically adding them to zones, cache, etc.
  • The only thing missing is a check that the RDATA of these records is correctly formed.
  • One impact of not checking your own records when loading or updating your zone data would be that any malformed records might not do the job they were expected to do - and this can be diagnosed in other ways. Perhaps think of this as a similar situation to having a typing mistake in the A record for a server.
  • Another potential impact of not checking your own records might be that you accidentally serve malformed records to other recursive servers that have not yet responded to the advisory (but this only applies to records that you have added or updated since installing the patched versions of BIND or applying the workaround).

What is the difference between the patched versions of BIND and the recently released beta versions?

ISC has released patched versions of BIND (9.9.2-P2 and 9.8.4-P2) as a solution for production environments. In parallel we have BIND 9.9.3 and 9.8.5 under development and as part of the release cycle we released versions  9.9.3b2 and 9.8.5b2 that are not vulnerable to this defect.

  • Versions 9.9.3b2 and 9.8.5b2 are protected from exploitation of the CVE-2013-2266 vulnerability but they are still beta code and not recommended for use in production environments.
  • BIND 9.9.3 and 9.8.5 will not use regex support from libregex, but instead will be implementing a new parsing module that is native to the BIND product.
  • We welcome testers of pre-release code, but please note that new code is not production-ready until it has completed a full beta and release-candidate cycle and has undergone public scrutiny.
  • For production, either the workaround or one of the -P2 versions is our recommendation at this time.

What is the difference between deploying the patched versions of BIND versus implementing the documented workaround?

  • The workaround and the patched versions of BIND are functionally indistinguishable.
  • The patched versions of BIND have the same change made to the build environment that we recommend in the workaround.
  • In both cases, you will need to build a new version of BIND for distribution and installation on your production servers.
  • One minor advantage of the patched versions over the workaround is in version control and identification - when running any of the BIND binaries, they will report that they are from a patched build. This will not be the case (by default) when applying the workaround.
If deploying the workaround, you can manually change the version of BIND in your build
Prior to building BIND from the updated source tarball, you can update the version that will be reported by the BIND binaries by modifying the file ./version in the top directory of the BIND source code tarball.

Will there be a patch for BIND 9.7?

  • We do not plan to release a patch for BIND 9.7. Although we may on occasion release patches for EOL versions of BIND, the patches that are being released for BIND 9.8 and 9.9 are functionally
    equivalent to the documented workaround, and do not introduce any new code. Those still using BIND 9.7 will be able to employ the workaround until such time they are able to upgrade to a supported version of BIND.

If Windows versions are not affected, why are you releasing Windows zip files for 9.8.4-P2 and 9.9.2-P2?

  • As previously stated, Windows builds of BIND are not affected.
  • The Windows binaries for 9.8.4-P2 and 9.9.2-P2 are functionally identical to 9.8.4-P1 and 9.9.2-P1 (respectively) except that they identify as the -P2 versions (e.g. when named is invoked with -V, or when queried for version.bind).
  • We are releasing these zip files with Windows binaries for the convenience of customers who operate a mixed Windows/Unix server environment and who prefer to have only one version of BIND deployed across their nameservice infrastructure.

If I am not accepting zone transfers, do I still have to worry?

  • Unfortunately, there are multiple potential vectors for this vulnerability.
  • We would like to tell you what they are, but we don't want to tell "the bad guys."
  • You should not assume that you can protect a vulnerable version of BIND by not using or explicitly disallowing certain features. You MUST apply the workaround or upgrade to a patched version to be protected against this vulnerability.