ISC Responds to Customer Questions About CVE-2015-5745 (glibc buffer overflow vulnerability.)

Robert Edmonds 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.
> 
> https://www.isc.org/blogs/a-few-words-about-the-glibc-vulnerability-cve-2015-7547/

Hi, Michael:

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
     library.

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:

    http://developerblog.redhat.com/2016/02/17/upgrading-the-gnu-c-library-within-red-hat-enterprise-linux/

    [...]

    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.

    [...]

-- 
Robert Edmonds


More information about the bind-users mailing list