Security Exploit in DNS Servers (fwd)

> ---------- Forwarded message ----------
> Date: Fri, 28 Jun 2002 17:17:10 -0400 (EDT)
> From: CERT Advisory <cert-advisory@cert.org>
> To: cert-advisory@cert.org
> Subject: 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.

>    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)

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

>    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

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

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

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

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

>      The  DNS  resolver  code  supplied  by  Cray,  Inc.  in  Unicos and
>      Unicos/mk  is  vulnerable. SPR 722619 has been opened to track this
>      problem.

>      See
>      ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-02:28.
>      resolv.asc

>      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/

>      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
>      bind-bugs@isc.org.
>      Query   about   BIND   4   and   BIND  8  should  be  addressed  to
>      bind-bugs@isc.org.
>      Query about BIND 9 should be addressed to bind9-bugs@isc.org.

>      Microsoft  products do not use the libraries in question. Microsoft
>      products are not affected by this issue.

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

>      See
>      ftp://ftp.NetBSD.ORG/pub/NetBSD/security/advisories/NetBSD-SA2002-0
>      06.txt.asc

>      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 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
>      _________________________________________________________________

>     1. http://www.pine.nl/advisories/pine-cert-20020601.asc

>    ______________________________________________________________________

>    This document is available from:
>    http://www.cert.org/advisories/CA-2002-19.html
>    ______________________________________________________________________

>    Email: cert@cert.org
>           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 majordomo@cert.org. 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.

>    June 28, 2002:  Initial release