Great, another zlib-style library hunt. Andrew Tait System Administrator Country NetLink Pty, Ltd E-Mail: [EMAIL PROTECTED] WWW: http://www.cnl.com.au 30 Bank St Cobram, VIC 3644, Australia Ph: +61 (03) 58 711 000 Fax: +61 (03) 58 711 874
"It's the smell! If there is such a thing." Agent Smith - The Matrix ----- Original Message ----- From: "CERT Advisory" <cert-advisory@cert.org> To: <cert-advisory@cert.org> Sent: Saturday, June 29, 2002 7:18 AM Subject: CERT Advisory CA-2002-19 Buffer Overflow in Multiple DNS Resolver Libraries > > > -----BEGIN PGP SIGNED MESSAGE----- > > CERT Advisory CA-2002-19 Buffer Overflow in Multiple DNS Resolver Libraries > > Original release date: June 28, 2002 > Last revised: -- > Source: CERT/CC > > A complete revision history can be found at the end of this file. > > Systems Affected > > Applications using vulnerable implementations of the Domain Name > System (DNS) resolver libraries, which include, but are not limited > to: > > * Internet Software Consortium (ISC) Berkeley Internet Name Domain > (BIND) DNS resolver library (libbind) > > * Berkeley Software Distribution (BSD) DNS resolver library (libc) > > > Overview > > A buffer overflow vulnerability exists 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 this vulnerability to execute arbitrary code or cause a denial > of service on a vulnerable system. > > > I. Description > > 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. > > Multiple implementations of DNS resolver libraries contain a remotely > exploitable buffer overflow vulnerability in the way the resolver > handles DNS responses. Both BSD (libc) and ISC (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 makes use > of vulnerable resolver libraries are likely to be affected, therefore > this problem is not limited to DNS or BIND servers. > > Vulnerability Note VU#803539 lists the vendors that have been > contacted about this vulnerability: > > http://www.kb.cert.org/vuls/id/803539 > > This vulnerability is not the same as the Sendmail issue discussed in > Vulnerability Note VU#814627: > > http://www.kb.cert.org/vuls/id/814627 > > > II. Impact > > An attacker who is able to send malicious DNS responses could remotely > exploit this vulnerability 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. > > 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 this vulnerability. > > > III. Solution > > Upgrade to a corrected version of the DNS resolver libraries > > 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. > > Applications that are statically linked must be recompiled using > patched resolver libraries. Applications that are dynamically > linked do not need to be recompiled; however, running services need > to be restarted in order to use the patched resolver libraries. > > System administrators should consider the following process when > addressing this issue: > > 1. Patch or obtain updated resolver libraries. > > 2. Restart any dynamically linked services that make use of the > resolver libraries. > > 3. Recompile any statically linked applications using the patched or > updated resolver libraries. > > Use a local caching DNS server > > Using a local caching DNS server that reconstructs DNS responses > will prevent malicious responses from reaching systems using > vulnerable DNS resolver libraries. For example, BIND 9 reconstructs > responses in this way, with the exception of forwarded dynamic DNS > update messages. Note that BIND 8 does not reconstruct all > responses; therefore this workaround may not be effective when > using BIND 8 as a caching DNS server. > > > Appendix A. - Vendor Information > > This appendix contains information provided by vendors for this > advisory. When vendors report new information to the CERT/CC, we > update this section and note the changes in our revision history. If a > particular vendor is not listed below, we have not received their > comments. > > Compaq > > SOURCE: Compaq Computer Corporation, a wholly-owned subsidiary of > Hewlett-Packard Company and Hewlett-Packard Company HP Services > Software Security Response Team > > x-ref:SSRT2270 > > At the time of writing this document, Compaq is currently > investigating the potential impact to Compaq's released Operating > System software products. > > As further information becomes available Compaq will provide notice > of the completion/availibility of any necessary patches through > standard product and security bulletin announcements and be > available from your normal HP Services support channel. > > Cray, Inc. > > The DNS resolver code supplied by Cray, Inc. in Unicos and > Unicos/mk is vulnerable. SPR 722619 has been opened to track this > problem. > > FreeBSD > > See > ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-02:28. > resolv.asc > > GNU adns > > 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. > > For more information on GNU adns, see: > > http://www.gnu.org/software/adns/ > http://www.chiark.greenend.org.uk/~ian/adns/ > > Internet Software Consortium > > All versions of BIND 4 from 4.8.3 prior to BIND 4.9.9 are > vulnerable. > All versions of BIND 8 prior to BIND 8.2.6 are vulnerable. > All versions of BIND 8.3.x prior to BIND 8.3.3 are vulnerable. > BIND versions BIND 9.2.0 and BIND 9.2.1 are vulnerable. > BIND version 4.8 does not appear to be vulnerable. > BIND versions BIND 9.0.x and BIND 9.1.x are not vulnerable. > 'named' itself is not vulnerable. > Updated releases can be found at: > > ftp://ftp.isc.org/isc/bind/src/4.9.9/ > ftp://ftp.isc.org/isc/bind/src/8.2.6/ > ftp://ftp.isc.org/isc/bind/src/8.3.3/ > ftp://ftp.isc.org/isc/bind/contrib/ntbind-8.3.3/ > > 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. > > In addition the BIND 9 'named' can be used to prevent malformed > answers reaching vulnerable clients. > > Vendors wishing additional patches should contact > [EMAIL PROTECTED] > Query about BIND 4 and BIND 8 should be addressed to > [EMAIL PROTECTED] > Query about BIND 9 should be addressed to [EMAIL PROTECTED] > > Microsoft > > Microsoft products do not use the libraries in question. Microsoft > products are not affected by this issue. > > OpenBSD > > [T]he resolver libraries in question got copied far and wide. They > used to have a hell of a lot of bugs in them. > > 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. > > NetBSD > > See > ftp://ftp.NetBSD.ORG/pub/NetBSD/security/advisories/NetBSD-SA2002-0 > 06.txt.asc > > Network Appliance > > Some NetApp systems are vulnerable to this problem. Check NOW > (http://now.netapp.com) for information on whether your system is > vulnerable and the appropriate patch release that you should > install. > > SGI > > SGI is looking into the matter. > > > _________________________________________________________________ > > The CERT Coordination Center thanks Joost Pol of PINE-CERT and the > FreeBSD Project for their analysis of these vulnerabilities. > _________________________________________________________________ > > Feedback can be directed to the authors: Art Manion and Jason A. > Rafail > _________________________________________________________________ > > > Appendix B. - References > > 1. http://www.pine.nl/advisories/pine-cert-20020601.asc > > ______________________________________________________________________ > > This document is available from: > http://www.cert.org/advisories/CA-2002-19.html > ______________________________________________________________________ > > > CERT/CC Contact Information > > Email: [EMAIL PROTECTED] > Phone: +1 412-268-7090 (24-hour hotline) > Fax: +1 412-268-6989 > Postal address: > CERT Coordination Center > Software Engineering Institute > Carnegie Mellon University > Pittsburgh PA 15213-3890 > U.S.A. > > CERT/CC personnel answer the hotline 08:00-17:00 EST(GMT-5) / > EDT(GMT-4) Monday through Friday; they are on call for emergencies > during other hours, on U.S. holidays, and on weekends. > > Using encryption > > We strongly urge you to encrypt sensitive information sent by email. > Our public PGP key is available from > http://www.cert.org/CERT_PGP.key > > If you prefer to use DES, please call the CERT hotline for more > information. > > Getting security information > > CERT publications and other security information are available from > our web site > > http://www.cert.org/ > > To subscribe to the CERT mailing list for advisories and bulletins, > send email to [EMAIL PROTECTED] Please include in the body of your > message > > subscribe cert-advisory > > * "CERT" and "CERT Coordination Center" are registered in the U.S. > Patent and Trademark Office. > ______________________________________________________________________ > > NO WARRANTY > Any material furnished by Carnegie Mellon University and the Software > Engineering Institute is furnished on an "as is" basis. Carnegie > Mellon University makes no warranties of any kind, either expressed or > implied as to any matter including, but not limited to, warranty of > fitness for a particular purpose or merchantability, exclusivity or > results obtained from use of the material. Carnegie Mellon University > does not make any warranty of any kind with respect to freedom from > patent, trademark, or copyright infringement. > _________________________________________________________________ > > Conditions for use, disclaimers, and sponsorship information > > Copyright 2002 Carnegie Mellon University. > > > Revision History > > June 28, 2002: Initial release > > -----BEGIN PGP SIGNATURE----- > Version: PGP 6.5.8 > > iQCVAwUBPRzRIKCVPMXQI2HJAQFUUAP+JrIx1x3vF0BL7zFcURQSOOIsmEoGzqAP > B+xs5kf4Oy5uYRRLASvYFh/XjnyGXIA5v8ECWx00B52PBKi7aPQS5o4Kiz1rxkFf > +c5oziLDXNwy4Vj2ArUjdzM47Ghrq8QXHBOoHaK5OWAF6tywbOklHt50T61OWzGu > 5WGow8NNw9I= > =PbO6 > -----END PGP SIGNATURE----- > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]