A Few Words About the glibc Vulnerability, CVE-2015-7547

On February 16th, news reached ISC about CVE-2015-7547, a serious defect in the getaddrinfo() library call in glibc. This defect allows an attacker to cause buffer overflow to occur, creating the possibility of remote code execution in some circumstances. ISC has been asked by several of our customers and partners to comment on whether this vulnerability should be of concern to operators using our products.

As general advice

Of course this should be of concern to anyone operating a system which uses glibc. A common system call containing a bug which potentially permits remote code execution calls for immediate patching and the best solution is to immediately seek a patched version of glibc which has been secured to prevent this vulnerability.

Speaking specifically about ISC’s products and their exposure

In response to requests from our customers, we have examined our BIND, ISC DHCP, and Kea products to assess the risk this vulnerability poses to customers using those products to provide services.

• Concerning BIND – the named nameserver daemon which is the heart of BIND does not make use of the getaddrinfo() function from the system library in any way which we believe can be exploited. Instead it performs resolution using its own code (including a function in named with the same name, but which is different from the getaddrinfo() from the system library). However, the system library’s getaddrinfo() call is used by several utility programs (e.g. dig, delv) which are distributed as part of the BIND package. Despite the fact that nameserver risk exposure is minimal, fixing the system libraries is still strongly recommended.
• Concerning ISC DHCP – ISC DHCP can make use of getaddrinfo() in some circumstances. We do not believe the risk to DHCP operators to be high but fixing the system libraries as soon as possible is still strongly recommended.
• Concerning Kea – the Kea DHCP server does not make use of getaddrinfo(). Some of the unit tests which are distributed with the source code can use getaddrinfo() but the risk to Kea server operators is minimal. We still recommend that you fix your system libraries as soon as possible because of all of the other components of a system that may make use of this common library call, but Kea itself should not be at risk.

Static and dynamic linking

On most systems, programs which are built as part of the ISC products are configured to be dynamically linked, making use of system libraries which are found at runtime. However, it is possible to deliberately build statically linked binaries in which library routines are incorporated into the binary images produced at compile time. If you have built statically linked versions of ISC programs you must fix your system library first and then rebuild and relink the ISC products to ensure that you are now using the corrected library. Most users, however, are using dynamically linked libraries (which are the default build option) and need only fix their libraries and then stop and restart the ISC product – re-linking is not usually necessary for those who have built using the default options.

Concerning countermeasures

The CVE-2015-7547 announcement contains, as do a number of additional articles which are circulating concerning the vulnerability, a list of recommended countermeasures intended to prevent successful exploitation of the defect. Among the recommendations are such proposed countermeasures as blocking UDP packets that are larger than 512 bytes, limiting the permitted size of TCP replies, and discouraging the use of EDNS0. ISC would like to advise customers that we recommend caution when applying such measures as they can interfere with DNS operations, causing problems of their own.

Responses that require more than 512 bytes are legal and normal in DNS and proper EDNS0 operation is important for DNSSEC validation and other critical DNS functionality.

We continue to recommend that the best course of action is to replace the vulnerable library on affected systems but if you must, for some reason, adopt any of the countermeasures we counsel closely monitoring your DNS for signs of problems which may be created or exacerbated by the specified measures.