ISC Responds to Customer Questions About CVE-2015-5745 (glibc buffer overflow vulnerability.)
edmonds at mycre.ws
Fri Feb 19 22:33:05 UTC 2016
Michael McNally wrote:
> This week a major vulnerability in glibc was announced. In response to
> questions from our customers and users, ISC has provided a response for
> operators who are wondering what CVE-2015-5745 means for BIND, ISC DHCP,
> and Kea server operators.
I'm not sure how realistic this statement is:
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
You might want to do that out of an abundance of caution, but it's my
understanding that the vulnerable code is either impossible or very
difficult to statically link into a binary. The CVE title carries the
name of the public API function getaddrinfo() that the vulnerable code
can be reached through, and getaddrinfo() does reside in libc.so/libc.a,
but the vulnerable code is actually in an internal function
_nss_dns_gethostbyname4_r(), which is located in glibc's nss_dns module
and there is TTBOMK no way to statically link NSS modules into glibc.
Red Hat published an interesting blog article earlier this week that
touches on glibc and static linking:
glibc provides only limited support for static linking. Most
programs are dynamically linked, so a glibc update directly affects
them. This is true both for operating system components and software
not provided by Red Hat.
Even statically linked binaries can break during glibc upgrades if
they use the Name Service Switch (NSS). Static linking of glibc is
not supported on Red Hat Enterprise Linux, but the potential
breakage is nevertheless a reason to minimize changes in this area.
More information about the bind-users