Original release date: June 28, 2002<br>
Last revised: November 19, 2008<br>
Source: CERT/CC<br>
<p>
A complete revision history can be found at the end of this file.
</p>
<br>
<a name="affected"></a>
<h3>Systems Affected</h3>
<p>Applications using vulnerable implementations of the Domain Name System
(DNS) resolver libraries, which include, but are not limited to
<ul>
<li>
Internet Software Consortium (ISC) Berkeley Internet Name Domain (BIND) DNS resolver library (libbind)
</li>
<li>
Berkeley Software Distribution (BSD) DNS resolver library (libc)
</li>
<li>
GNU DNS resolver library (glibc)
</li>
</ul>
<br>
<a name="overview"></a>
<h2>Overview</h2>
<p>Buffer overflow vulnerabilities exist in multiple implementations
of DNS resolver libraries. Operating systems and applications that
utilize vulnerable DNS resolver libraries may be affected. A remote
attacker who is able to send malicious DNS responses could potentially
exploit these vulnerabilities to execute arbitrary code or cause a denial
of service on a vulnerable system.
</p>
<br>
<a name="description"></a>
<h2>I. Description</h2>
<p>
The DNS protocol provides name, address, and other information about
Internet Protocol (IP) networks and devices. To access DNS
information, a network application uses the resolver to perform DNS
queries on its behalf. Resolver functionality is commonly implemented
in libraries that are included with operating systems.
</p>
<p>
Multiple implementations of DNS resolver libraries contain remotely
exploitable buffer overflow vulnerabilities in the code used to handle
DNS responses. Both BSD (libc) and ISC BIND (libbind) resolver
libraries share a common code base and are vulnerable to this problem;
any DNS resolver implementation that derives code from either of these
libraries may also be vulnerable. Network applications that use
vulnerable resolver libraries are likely to be affected, therefore
this problem is not limited to DNS or BIND servers.
</p>
<p>
Two sets of responses could trigger buffer overflows in vulnerable
DNS resolver libraries: responses for host names or addresses,
and responses for network names or addresses. The GNU glibc
resolver addressed the vulnerability in handling responses for host
resolution in version 2.1.3. However, versions of glibc prior to and
including 2.2.5 are vulnerable to responses for network resolution, as
explained below in the GNU glibc <a href="#glibc">vendor
statement</a>. BSD (libc) and ISC BIND (libbind) resolvers are
vulnerable to both types of responses.
</p>
<p>
VU#803539 (<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2002-0651">CAN-2002-0651</a>) lists vendors that have been contacted and provides further information about these vulnerabilities:
<blockquote>
<a href="http://www.kb.cert.org/vuls/id/803539">http://www.kb.cert.org/vuls/id/803539</a>
</blockquote>
</p>
<p>
VU#542971 (<a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2002-0684">CAN-2002-0684</a>) describes the network name and address resolution vulnerability in the GNU libc library (glibc):
<blockquote>
<a href="http://www.kb.cert.org/vuls/id/542971">http://www.kb.cert.org/vuls/id/542971</a>
</blockquote>
</p>
<p>
NetBSD Security Advisory 2002-006 also explains these vulnerabilities in detail:
<blockquote>
<a href="ftp://ftp.NetBSD.ORG/pub/NetBSD/security/advisories/NetBSD-SA2002-006.txt.asc">ftp://ftp.NetBSD.ORG/pub/NetBSD/security/advisories/NetBSD-SA2002-006.txt.asc</a>
</blockquote>
</p>
<p>
Note that these vulnerabilities are not related to the Sendmail DNS map
issue discussed in <a href="http://www.kb.cert.org/vuls/id/814627">VU#814627</a>.
</p>
<br>
<A NAME="impact"></a>
<h2>II. Impact</h2>
<p>
An attacker who is able to send malicious DNS responses could remotely
exploit these vulnerabilities to execute arbitrary code or cause a denial of
service on vulnerable systems. Any code executed by the attacker would run
with the privileges of the process that calls the vulnerable resolver
function.
</p>
<p>
Note that an attacker could cause one of the victim's network services
to make a DNS request to a DNS server under the attacker's control. This
would permit the attacker to remotely exploit these vulnerabilities.
</p>
<br>
<A NAME="solution"></a>
<H2>III. Solution</H2>
<b>Upgrade to a corrected version of the DNS resolver libraries</b>
<blockquote>
<p>
Note that DNS resolver libraries can be used by multiple applications
on most systems. It may be necessary to upgrade or apply multiple
patches and then recompile statically linked applications.
</p>
<p>
Applications that are <i>statically</i> linked must be recompiled
using patched resolver libraries. Applications that are
<i>dynamically</i> linked do not need to be recompiled; however,
running services need to be restarted in order to use the patched
resolver libraries.
</p>
<p>
System administrators should consider the following process when
addressing this issue:
<ol>
<li>Patch or obtain updated resolver libraries.</li>
<li>Restart any dynamically linked services that use the resolver libraries.</li>
<li>Recompile any statically linked applications using the patched or updated resolver libraries.</li>
</ol>
</p>
</blockquote>
<b>Use of a local caching DNS server is not an effective workaround</b>
<blockquote>
<p>
When this advisory was initially published, it was thought that a
caching DNS server that reconstructs DNS responses would prevent
malicious code from reaching systems with vulnerable resolver
libraries.
</p>
<p>
This workaround is not sufficient. It does not prevent some DNS
responses that contain malicious code from reaching clients, whether
or not the responses are reconstructed by a local caching DNS server.
DNS responses containing code that is capable of exploiting the
vulnerabilities described in <a
href="http://www.kb.cert.org/vuls/id/803539">VU#803539</a> and <a
href="http://www.kb.cert.org/vuls/id/542971">VU#542971</a> can be
cached and reconstructed before being transmitted to clients. Since
the server may cache the responses, the malicious code could persist
until the server's cache is purged or the entries expire.
</p>
<p>
The only complete solution to this problem is to upgrade to a
corrected version of the DNS resolver libraries as noted above.
</p>
</blockquote>
<br>
<A NAME="vendors"></a>
<H2>Appendix A. - Vendor Information</H2>
<P>
This appendix contains information provided by vendors for this
advisory. When vendors report new information, this section is
updated and the changes are noted in the revision history. If a
vendor is not listed below, we have not received their comments.
</P>
<a name="apple"></a>
<h4><a href="http://www.apple.com/">Apple Computer, Inc.</a></h4>
<blockquote>
<p>
Mac OS X and Mac OS X Server are not vulnerable to the issue
described in this notice.
</p>
</blockquote>
<!-- end vendor -->
<a name="caldera"></a>
<h4><a href="http://www.caldera.com/">Caldera</a></h4>
<blockquote>
<p>
Caldera OpenLinux is affected (glibc):
<blockquote>
<a href="ftp://ftp.caldera.com/pub/security/OpenLinux/CSSA-2002-034.1.txt">ftp://ftp.caldera.com/pub/security/OpenLinux/CSSA-2002-034.1.txt</a>
</blockquote>
Caldera UnixWare is affected:
<blockquote>
<a href="ftp://ftp.caldera.com/pub/security/UnixWare/CSSA-2002-SCO.37.txt">ftp://ftp.caldera.com/pub/security/UnixWare/CSSA-2002-SCO.37.txt</a>
</blockquote>
</p>
</blockquote>
<!-- end vendor -->
<a name="compaq"></a>
<h4><a href="http://www.compaq.com/">Compaq</a></h4>
<blockquote>
<p>
SOURCE: Compaq Computer Corporation,
a wholly-owned subsidiary of
Hewlett-Packard Company
and Hewlett-Packard Company HP Services
Software Security Response Team
</p>
<p>x-ref:SSRT2270</p>
<p>
[Compaq (Hewlett-Packard) has released a security bulletin (<a href="http://wwss1pro.compaq.com/support/reference_library/viewdocument.asp?source=SRB0039W.xml&dt=11">SRB0039W</a>/SSRT2275) that addresses VU#803539 and other vulnerabilities.]
</p>
</blockquote>
<!-- end vendor -->
<a name="conectiva"></a>
<h4><a href="http://www.conectiva.com/">Conectiva</a></h4>
<blockquote>
<p>
Conectiva Linux supported versions (6.0, 7.0 and 8) are not vulnerable
to VU#803539 regarding glibc packages. Regarding VU#542971, these
same versions of Conectiva Linux are vulnerable but not in the default
installation, since <font face="courier">/etc/nsswitch.conf</font> ships without the dns parameter
in the "networks:" line.
</p>
<p>
Updated glibc packages which fix the second vulnerability, VU#542971, will be provided.
</p>
<p>
Please see Conectiva Linux Announcement <a href="http://distro.conectiva.com.br/atualizacoes/?id=a&anuncio=000507&idioma=en">CLSA-2002:507 (english)</a>.
</p>
</blockquote>
<!-- end vendor -->
<a name="cray"></a>
<h4><a href="http://www.cray.com/">Cray, Inc.</a></h4>
<blockquote>
<p>
The DNS resolver code supplied by Cray, Inc. in Unicos and Unicos/mk
is vulnerable. SPR 722619 has been opened to track this problem.
</p>
</blockquote>
<!-- end vendor -->
<a name="debian"></a>
<h4><a href="http://www.debian.org/">Debian</a></h4>
<blockquote>
<p>
Debian is vulnerable to the second vulnerability [VU#542971]:
<blockquote>
<font face="courier">
Debian 2.2 aka potato aka stable: glibc 2.1.3 does not contain the included patch<br>
Debian woody aka testing: glibc 2.2.5 does not contain the included patch<br>
Debian sid aka unstable: glibc 2.2.5 does not contain the included patch<br>
</font>
</blockquote>
</p>
<p>
We are working towards an updated library.
</p>
<p>
We are not vulnerable to the first vulnerability [VU#803539] as published in the
CERT Advisory CA-2002-19, though.
</p>
</blockquote>
<!-- end vendor -->
<a name="djbdns"></a>
<h4><a href="http://cr.yp.to/djbdns.html">djbdns</a></h4>
<blockquote>
<p>
djbdns does not have these bugs. djbdns has never used any
BIND-derived code. djbdns, including the djbdns client library, is
covered by a $500 security guarantee. The djbdns client library is
free for use by other packages in place of BIND's libresolv. See <a
href="http://cr.yp.to/djbdns.html">http://cr.yp.to/djbdns.html</a>.
</p>
<p>
Elsewhere in this advisory, CERT and the BIND company suggest that
administrators do not need to rush to upgrade their libresolv-based
clients if they are using BIND 9 caches. The idea is that (1) BIND 9
caches never put CNAME records into the answer section of a DNS packet
except at the top and (2) the BIND company believes that these
libresolv bugs cannot be triggered by answer sections with all CNAME
records at the top.
</p>
<p>
dnscache, the caching component of djbdns, is like the BIND 9 cache in
all relevant respects. Specifically, it never puts CNAME records into
the answer section except at the top. (This is the normal behavior
for DNS caches; BIND 4 and BIND 8 are abnormal.)
</p>
<p>
However, it is simply not true that clients are protected by caches.
Attackers can send unusual packets directly to clients, using the same
well-known techniques used to selectively forge DNS responses. I do
not endorse the suggestion of relying on caches (whether BIND 9 or
dnscache) as a ``solution'' to the libresolv bugs. All libresolv-based
clients must be upgraded immediately.
</p>
<p>
There are exceptions. Sites that use a local dnscache on every
machine, with local firewalls preventing forgery of 127.0.0.1 and with
proper IP-address checks in client libraries, are immune to
cache-to-client packet forgery, as are sites that use IPSEC. However,
even at those sites, libresolv-based clients should be upgraded
immediately; the ability of the cache to take control of client
programs, rather than simply providing DNS data, is a violation of
standard security policy.
</p>
</blockquote>
<!-- end vendor -->
<a name="freebsd"></a>
<h4><a href="http://www.FreeBSD.org/">FreeBSD</a></h4>
<blockquote>
<p>
FreeBSD has released FreeBSD-SA-02:28.resolv:
<blockquote>
<a href="ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-02:28.resolv.asc">ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-02:28.resolv.asc</a>
</blockquote>
</p>
</blockquote>
<a name="adns"></a>
<h4><a href="http://www.gnu.org/software/adns/">GNU adns</a></h4>
<blockquote>
<p>
adns is not derived from BIND libresolv. Furthermore, it does not
support a gethostbyname-like interface (which is where the bug in BIND
libresolv is). Therefore, it is not vulnerable.
</p>
<p>
For more information on GNU adns, see:
<blockquote>
<a href="http://www.gnu.org/software/adns/">http://www.gnu.org/software/adns/</a>
<br><br>
<a href="http://www.chiark.greenend.org.uk/~ian/adns/">http://www.chiark.greenend.org.uk/~ian/adns/</a>
</blockquote>
</p>
</blockquote>
<!-- end vendor -->
<a name="glibc"></a>
<h4><a href="http://www.gnu.org/software/libc/libc.html">GNU glibc</a></h4>
<blockquote>
<p>
For resolving host names and addresses via DNS, Version 2.1.2 and earlier versions of the GNU C Library are vulnerable. Later versions are not vulnerable.
</p>
<p>
For the less commonly used action of resolving network names and addresses via DNS as per Internet RFC 1011, Version 2.2.5 and earlier versions are vulnerable.
</p>
<p>
To work around the problems, modify the file <font face="courier">/etc/nsswitch.conf</font> so that it contains "hosts:" and "networks:" lines that do not mention "dns".
For example, you might use the following lines in your <font face="courier">/etc/nsswitch.conf</font> file:
<blockquote>
<font face="courier">
# This "networks:" line omits "dns" to work around a bug in glibc<br>
# 2.2.5 and earlier.<br>
networks: files nisplus<br>
<br>
# This "hosts:" line omits "dns" to work around a bug in glibc 2.1.2<br>
# and earlier.<br>
hosts: nisplus [NOTFOUND=return] files<br>
</font>
</blockquote>
Most GNU/Linux distributions with glibc 2.1.3 and later ship with a
line like "networks: files" in <font face="courier">/etc/nsswitch.conf</font> and thus unless this
line is changed they are not vulnerable.
</p>
<p>
To fix the problem instead of working around it, we suggest upgrading
to Version 2.1.3 or later, and applying the following patch, taking
care to relink any statically linked applications that use the
affected functions. This patch can also be found at:
<br><br>
<<a href="http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/resolv/nss_dns/dns-network.c.diff?r1=1.10&r2=1.10.2.1&cvsroot=glibc">http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/resolv/nss_dns/dns-network.c.diff?<br>r1=1.10&r2=1.10.2.1&cvsroot=glibc</a>>
<blockquote>
<font face="courier">
===================================================================<br>
RCS file: /cvs/glibc/libc/resolv/nss_dns/dns-network.c,v<br>
retrieving revision 1.10<br>
retrieving revision 1.10.2.1<br>
diff -u -r1.10 -r1.10.2.1<br>
--- libc/resolv/nss_dns/dns-network.c 2001/07/06 04:55:39 1.10<br>
+++ libc/resolv/nss_dns/dns-network.c 2002/07/02 09:38:29 1.10.2.1<br>
@@ -328,7 +328,9 @@<br>
}<br>
cp += n;<br>
*alias_pointer++ = bp;<br>
- bp += strlen (bp) + 1;<br>
+ n = strlen (bp) + 1;<br>
+ bp += n;<br>
+ linebuflen -= n;<br>
result->n_addrtype = class == C_IN ? AF_INET : AF_UNSPEC;<br>
++have_answer;<br>
}<br>
</font>
</blockquote>
</p>
</blockquote>
<!-- end vendor -->
<a name="esl"></a>
<h4><a href="http://www.guardiandigital.com/">Guardian Digital</a></h4>
<blockquote>
<p>
Please see EnGarde Secure Linux Security Advisory <a href="http://www.linuxsecurity.com/advisories/other_advisory-2207.html">ESA-20020724-018</a>.
</p>
</blockquote>
<!-- end vendor -->
<a name="hp"></a>
<h4><a href="http://www.hp.com/">Hewlett-Packard Company</a></h4>
<blockquote>
<p>
HEWLETT-PACKARD COMPANY SECURITY BULLETIN: HPSBUX0208-209<br>
Originally issued: 12 Aug 2002<br>
<br>
reference id: VU#803539, SSRT2316<br>
<br>
HP Published Security Bulletin HPSBUX0208-209 with solutions for
HP9000 Series 700/800 running HP-UX releases 11.00 and 11.11 (11i)
with products using DNS resolver libraries, including, but not limited
to, BINDv920.INETSVCS-BIND.
</p>
<p>
This bulletin is available from the HP IT Resource Center page at: <a
href="http://itrc.hp.com/">http://itrc.hp.com</a> "Maintenance and
Support" then "Support Information Digests" and then "hp security
bulletins archive" search for bulletin HPSBUX0208-209.
</p>
<p>
reference id: VU#542971<br>
describes a specific aspect of this vulnerability as it affects the
GNU libc library (glibc):
<blockquote>
The glibc resolver used by HP Secure OS Software for Linux is
vulnerable. Please see Hewlett-Packard Company Security Bulletin
HPSBTL0207-053 for more information.
</blockquote>
</p>
</blockquote>
<!-- end vendor -->
<a name="ibm"></a>
<h4><a href="http://www.ibm.com/">IBM Corporation</a></h4>
<blockquote>
<p>
IBM is vulnerable to the above DNS stub resolver issues in both the 4.3 and 5.1 releases of AIX. A temporary patch is available through an efix pacakge. Efixes are available from <a href="ftp://ftp.software.ibm.com/aix/efixes/security/">ftp.software.ibm.com/aix/efixes/security</a>. See the README file in this directory for additional information on the efixes.
</p>
<p>
The following APARs will be available in the near future:
<blockquote>
AIX 4.3.3: IY32719
<br><br>
AIX 5.1.0: IY32746
</blockquote>
</p>
</blockquote>
<!-- end vendor -->
<a name="isc"></a>
<h4><a href="http://www.isc.org/">Internet Software Consortium</a></h4>
<blockquote>
<p>
All versions of BIND 4 from 4.8.1 prior to BIND 4.9.9 are vulnerable.<br>
All versions of BIND 8 prior to BIND 8.2.6 are vulnerable.<br>
All versions of BIND 8.3.x prior to BIND 8.3.3 are vulnerable.<br>
BIND versions BIND 9.2.0 and BIND 9.2.1 are vulnerable.<br>
<br>
The status of BIND 4.8 is unknown, assume that it is vulnerable.<br>
<br>
BIND versions BIND 9.0.x and BIND 9.1.x are not vulnerable.<br>
<br>
'named' itself is not vulnerable.<br>
<br>
Updated releases can be found at:
<blockquote>
<a
href="ftp://ftp.isc.org/isc/bind/src/4.9.9/">ftp://ftp.isc.org/isc/bind/src/4.9.9/</a>
<br><a
href="ftp://ftp.isc.org/isc/bind/src/8.2.6/">ftp://ftp.isc.org/isc/bind/src/8.2.6/</a>
<br><a
href="ftp://ftp.isc.org/isc/bind/src/8.3.3/">ftp://ftp.isc.org/isc/bind/src/8.3.3/</a>
<br><a
href="ftp://ftp.isc.org/isc/bind/contrib/ntbind-8.3.3/">ftp://ftp.isc.org/isc/bind/contrib/ntbind-8.3.3/</a>
</blockquote>
</p>
<p>BIND 9 contains a copy of the BIND 8.3.x resolver library (lib/bind).
This will be updated with the next BIND 9 releases (9.2.2/9.3.0) in the
meantime please use the original in BIND 8.3.3.</p>
<p>Vendors wishing additional patches should contact
bind-bugs@isc.org.<br>
Query about BIND 4 and BIND 8 should be addressed to
bind-bugs@isc.org.<br>
Query about BIND 9 should be addressed to bind9-bugs@isc.org. <br>
</p>
</blockquote>
<!-- end vendor -->
<a name="Juniper Networks"></a>
<h4><a href="http://www.juniper.net/">Juniper Networks</a></h4>
<blockquote>
<p>
All versions of Juniper Networks JUNOS software released prior to June
27, 2002, are potentially vulnerable to this bug. This includes JUNOS
versions 4.x, 5.0R1 through 5.0R4, 5.1R1 through 5.1R4, 5.2R1 through
5.2R3, and 5.3R1 through 5.3R2. (All releases of JUNOS software with
version 5.4 or higher are NOT vulnerable.) The bug has been corrected
as of June 27, 2002, and all future software releases will contain the
correction. All Juniper Networks customers are encouraged to contact
JTAC, the Juniper Networks Technical Assistance Center by telephone at
1-888-314-JTAC, or by E-mail at <a
href="mailto:support@juniper.net">support@juniper.net</a> for details
on the availability of corrected software.
</p>
</blockquote>
<!-- end vendor -->
<a name="metasolv"></a>
<h4><a href="http://www.metasolv.com/">MetaSolv</a></h4>
<blockquote>
<p>
The resolver code embedded in the DNS Server (Based on ISC BIND 8.2.3)
on both MetaSolv Policy Services 4.1 and 4.2 are vulnerable to CERT/CC
Advisory CA-2002-19. This issue is being tracked by MetaSolv under
Case #28230. The ISC Sanctioned Patches to 8.2.3 for this advisory
have been compiled and applied, and will be available in Policy
Services 4.2 Service Pack 1. Please contact MetaSolv Global Customer
Care (<a href="mailto:supporthd@metasolv.com">supporthd@metasolv.com</a>) for
availability and assistance.
</p>
</blockquote>
<!-- end vendor -->
<a name="mandrakesoft"></a>
<h4><a href="http://www.mandrakesoft.com/">MandrakeSoft</a></h4>
<blockquote>
<p>
Please see MandrakeSoft Security Advisory <a href="http://www.linux-mandrake.com/en/security/2002/MDKSA-2002-043.php">MDKSA-2002:043</a> (BIND) and <a href="http://www.linux-mandrake.com/en/security/2002/MDKSA-2002-050.php">MDKSA-2002:050</a> (glibc).
</p>
</blockquote>
<!-- end vendor -->
<a name="microsoft"></a>
<h4><a href="http://www.microsoft.com/">Microsoft</a></h4>
<blockquote>
<p>
Microsoft products do not use the libraries in question. Microsoft
products are not affected by this issue.
</p>
</blockquote>
<!-- end vendor -->
<a name="netbsd"></a>
<h4><a href="http://www.netbsd.org/">NetBSD</a></h4>
<blockquote>
<p>
NetBSD has released NetBSD Security Advisory 2002-006:
<blockquote>
<a href="ftp://ftp.NetBSD.ORG/pub/NetBSD/security/advisories/NetBSD-SA2002-006.txt.asc">ftp://ftp.NetBSD.ORG/pub/NetBSD/security/advisories/NetBSD-SA2002-006.txt.asc</a>
</blockquote>
</p>
</blockquote>
<!-- end vendor -->
<a name="netapp"></a>
<h4><a href="http://www.netapp.com/">Network Appliance</a></h4>
<blockquote>
<p> Some NetApp systems are vulnerable to this problem. Check NOW (<a
href="http://now.netapp.com">http://now.netapp.com</a>) for information on
whether your system is vulnerable and the appropriate patch release that
you should install. </p>
</blockquote>
<!-- end vendor -->
<a name="nortel"></a>
<h4><a href="http://www.nortelnetworks.com/">Nortel Networks</a></h4>
<blockquote>
<p>
The following Nortel Networks products are potentially affected by the vulnerability identified in CERT/CC Advisory CA-2002-19:
<ul>
<li>
NetID. A bulletin entitled "NetID BIND Bulletin", dated 7-12-02 has been issued and is available from the following Nortel Networks support contacts:<br>
<blockquote>
North America: 1-8004NORTEL or 1-800-466-7835
<br><br>
Europe, Middle East and Africa: 00800 8008 9009, or +44 (0) 870 907 9009
<br><br>
Contacts for other regions are available at <a href="http://www.nortelnetworks.com/help/contact/global/">www.nortelnetworks.com/help/contact/global/</a>
</blockquote>
</li>
<li>
Optivity NMS, which uses Sun Solaris operating systems supplied by third parties. Nortel Networks recommends following the mitigating practices in Sun Microsystems Inc.'s Alert Notification. Implementing such practices will not adversely impact this Nortel Networks product.
</li>
<br>
<li>
Also, the former Nortel Networks product Preside Policy Server divested to MetaSolv Software, Inc. in February 2002 uses BIND 8 and may be potentially affected.
</li>
</ol>
</p>
</blockquote>
<!-- end vendor -->
<a name="openbsd"></a>
<h4><a href="http://www.OpenBSD.org/">OpenBSD</a></h4>
<blockquote>
<p>
[T]he resolver libraries in question got copied far and wide. They used
to have a hell of a lot of bugs in them.
</p>
<p>Now might be a good time for people to compare each others' libraries
to each other. I would urge them to compare against the OpenBSD ones,
where we've spent a lot of time on, but of course we still missed this.
But perhaps people can then share some around. Not everyone is going to
move to the bind9 stuff, since it is very different. </p>
</blockquote>
<!-- end vendor -->
<a name="openpkg"></a>
<h4><a href="http://www.openpkg.org/">OpenPKG</a></h4>
<blockquote>
<p>
Please see OpenPKG Security Advisory <a href="http://www.openpkg.org/security/OpenPKG-SA-2002.006-bind.html">OpenPKG-SA-2002.006</a>.
</p>
</blockquote>
<!-- end vendor -->
<a name="openwall"></a>
<h4><a href="http://www.openwall.org/">Openwall Project</a></h4>
<blockquote>
<p>
No release or branch of Openwall GNU/*/Linux (Owl) is known to be
affected, due to Olaf Kirch's fixes for this problem getting into the
GNU C library more than two years ago.
</p>
<p>
The BIND 4.9.8-OW2 patch and BIND 4.9.9 release (and thus 4.9.9-OW1)
include fixes for this vulnerability, originally developed by
Jun-ichiro itojun Hagino of NetBSD. The updated patches are available
at the usual location:
<blockquote>
<a href="http://www.openwall.com/bind/">http://www.openwall.com/bind/</a>
</blockquote>
</p>
<p>
The BIND 4.9.x-OW patches provide certain security features which are
not a part of ISC's now deprecated BIND 4 and are recommended for use
by sites which chose to stick with BIND 4 for a little longer for whatever
reason. They aren't a part of Owl.
</p>
<p>
[VU#542971]
</p>
<p>
No release or branch of Openwall GNU/*/Linux (Owl) is affected in
default configuration as the "dns" NSS module isn't enabled for
network lookups in our default <font face="courier">/etc/nsswitch.conf</font> file.
</p>
<p>
The defect in "dns" module has been corrected in Owl-current on
2002/07/04 and that fix is included in the snapshot from 2002/07/07.
</p>
</blockquote>
<!-- end vendor -->
<a name="redhat"></a>
<h4><a href="http://www.redhat.com/">Red Hat Inc.</a></h4>
<blockquote>
<p>
Please see Red Hat Security Advisory <a href="http://rhn.redhat.com/errata/RHSA-2002-139.html">RHSA-2002:139</a> (glibc) and <a href="http://rhn.redhat.com/errata/RHSA-2002-133.html">RHSA-2002:133</a> (libbind).
</p>
</blockquote>
<!-- end vendor -->
<a name="securecomputing"></a>
<h4><a href="http://www.securecomputing.com/">Secure Computing Corporation</a></h4>
<blockquote>
<p>
This is the official Secure Computing response to CERT Advisory
CA-2002-19 Buffer Overflow in Multiple DNS Resolver Libraries. Note
that we are currently supporting three different firewalls with
different solutions to this vulnerability.
</p>
<p>
GAUNTLET (tm) FIREWALL & VPN (5.X and 6.0)<br>
Gauntlet software users should contact their operating system vendor
for a revised version of the library (on Solaris it is libresolv.so,
on HP-UX it is libnss_dns.1) in question and apply it as soon as it is
available.
</p>
<p>
GAUNTLET E-PPLIANCE FIREWALL & VPN (EPL 1.X and 2.0)<br>
Gauntlet e-ppliance would be vulnerable to this theoretical attack.
Secure Computing engineering is currently examining the issue in
preparation for a patch for the e-ppliance 300 and 1000 (all
versions).
</p>
<p>
SIDEWINDER(tm) FIREWALL & VPN (all releases including Sidewinder
Appliance)<br>
This buffer overflow vulnerability can not be exploited to gain access
to, or gain any valuable information from a Sidewinder. An attack
against one of the Sidewinder components using this vulnerability
would yield no special privileges (such as root access, shell access,
configuration information, etc.) due to Sidewinder's SecureOS(tm) Type
Enforcement(tm) technology (TE).
</p>
<p>
None of Sidewinder's critical services (proxies, ACL engine, etc.) do
direct DNS processing. Resolution is done by 'self contained' DNS
resolver processes which are not granted Type Enforcement access to
any of the services configuration data, nor could it access the data
contained by the service sessions, nor even execute a shell. This
process has no access to any system resources useful to an attacker.
And of course, there is no useful concept of root privilege on
Sidewinder. </p>
</blockquote>
<!-- end vendor -->
<a name="sendmail"></a>
<h4><a href="http://www.sendmail.org/">Sendmail</a></h4>
<blockquote>
<p>
Sendmail uses the BIND resolver API, and is commonly linked with the BIND resolver library (libbind). As a result, Sendmail could be leveraged to exploit this vulnerability.
</p>
<p>
Note that the DNS map problem that was addressed in Sendmail 8.12.5 is
a different issue, which is described in VU#814627:
<blockquote>
<a href="http://www.kb.cert.org/vuls/id/814627">http://www.kb.cert.org/vuls/id/814627</a>
</blockquote>
The announcement for Sendmail 8.12.5 also references the DNS map problem:
<blockquote>
<a href="http://www.sendmail.org/8.12.5.html">http://www.sendmail.org/8.12.5.html</a>
</blockquote>
</p>
</blockquote>
<!-- end vendor -->
<a name="sgi"></a>
<h4><a href="http://www.sgi.com/">SGI</a></h4>
<blockquote>
<p>
SGI IRIX is not vulnerable. Please see SGI Security Advisory <a href="ftp://patches.sgi.com/support/free/security/advisories/20020701-01-I">20020701-01-I</a> for more information.
</p>
</blockquote>
<!-- end vendor -->
<a name="sun"></a>
<h4><a href="http://www.sun.com/">Sun Microsystems</a></h4>
<blockquote>
<p>
The Solaris DNS resolver library (libresolv.so) is affected by this
issue in all currently supported versions of Solaris:
<blockquote>
Solaris 2.5.1, 2.6, 7, 8, and 9
</blockquote>
Sun has released patches as specified in Sun Alert ID <a href="http://sunsolve.Sun.COM/pub-cgi/retrieve.pl?doc=fsalert/46042">46042</a>.
</p>
<p>
Sun Security Bulletins are available from:
<blockquote>
<a href="http://sunsolve.sun.com/security">http://sunsolve.sun.com/security</a>
</blockquote>
</p>
</blockquote>
<!-- end vendor -->
<a name="suse"></a>
<h4><a href="http://www.suse.com/">SuSE</a></h4>
<blockquote>
<p>
Please see SUSE Security Announcement <a href="http://www.novell.com/linux/security/advisories/2002_026_glibc.html">SUSE-SA:2002:026</a> (previously located <a href="http://www.suse.com/de/security/2002_026_glibc.html">here</a>). See also <a href="http://www.novell.com/linux/security/securitysupport.html">SUSE Linux Enterprise Security</a>.
</p>
</blockquote>
<!-- end vendor -->
<a name="trustix"></a>
<h4><a href="http://www.trustix.com/">Trustix</a></h4>
<blockquote>
<p>
Please see Trustix Secure Linux Security Advisory <a href="http://www.trustix.net/errata/misc/2002/TSL-2002-0061-bind.asc.txt">#2002-0061</a>.
</p>
</blockquote>
<!-- end vendor -->
<hr noshade>
<p>
The CERT Coordination Center thanks Joost Pol of PINE-CERT, the
FreeBSD Project, the NetBSD Project, and David Conrad of <a href="http://www.nominum.com/">Nominum</a> for
information used in this document.
</p>
<p></p>
<hr noshade>
<p>Feedback can be directed to the authors: <a
href="mailto:cert@cert.org?subject=CA-2002-19%20Feedback%20VU%23803539">Art Manion and Jason A. Rafail</a>.
</p>
<hr noshade>
<p>
<a name="references">
<br>
<h2>Appendix B. - References</h2></a>
<ol>
<li><a href="http://www.pine.nl/advisories/pine-cert-20020601.asc">http://www.pine.nl/advisories/pine-cert-20020601.asc</a>
</li>
<li><a href="ftp://ftp.NetBSD.ORG/pub/NetBSD/security/advisories/NetBSD-SA2002-006.txt.asc">ftp://ftp.NetBSD.ORG/pub/NetBSD/security/advisories/NetBSD-SA2002-006.txt.asc</a></li>
<li><a href="ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-02:28.resolv.asc">ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-02:28.resolv.asc</a></li>
<li><a href="http://www.gnu.org/manual/glibc-2.2.5/html_node/Name-Service-Switch.html#Name%20Service%20Switch">http://www.gnu.org/manual/glibc-2.2.5/html_node/Name-Service-Switch.html#Name%20Service%20Switch</a></li>
</ol>
<br>
<!--#include virtual="/include/footer_nocopyright.html" -->
<p>
Copyright 2002 Carnegie Mellon University.
</p>
<p>
Revision History
</p>
<p>
<small>
June 28, 2002: Initial release<br>
June 29, 2002: Updated NetBSD references, addded Sendmail statement,
reformatted vendor statements, added CVE reference, added Juniper
statement<br>
June 30, 2002: Updated ISC statement<br>
July 1, 2002: Added Apple, Sun, and Openwall statements<br>
July 10, 2002: Added IBM statement and GNU glibc statements<br>
July 18, 2002: Added reference to VU#542971, added description of
network and host responses and glibc vulnerability, added Secure
Computing statement, updated Thanks statement, added Name Service
Switch reference<br>
July 25, 2002: Added djbns, Nortel, HP, Trustix, SGI, Conectiva, SuSE,
Red Hat, OpenPKG, and Guardian Digital statements, updated IBM
statement<br>
July 26, 2002: Added MetaSolv statement, updated HP statement<br>
August 9, 2002: Updated Red Hat statement<br>
August 14, 2002: Changed title to reflect plural "overflows", changed references to plural "vulnerabilities", re-ordered Description section, added firewall statement to caching DNS server workaround, updated HP, Conectiva, and Openwall statements, added SuSE URL, added Debian and MandrakeSoft statements, re-formatted fixed-width text<br>
August 27, 2002: Deprecated caching DNS server workaround, updated Caldera statement<br>
August 28, 2002: Updated ISC and Sun statements<br>
September 9, 2002: Updated Compaq statement<br>
November 19, 2008: Update SUSE statement<br>
</small>
</p>
|