Re: Bug in Bind 9.1.0?
On Wednesday, February 07, 2001, 11:15:48 PM, I wrote: I believe ISC is still investigating this. Haven't heard from the FreeBSD people yet, altough they were the first I reported this to... In the meantime, I was informed by Doug Barton (who maintains the Bind port in FreeBSD) that "the FreeBSD team is currently investigating solutions to the problems brought to light by version 9.1.0 of BIND. Meanwhile, our port of BIND 9 has been updated to use BIND version 9.1.1rc1 which, in addition to significant bug fixes contains code that turns those failure modes into logged warnings". Those warnings look like this: Feb 9 13:56:04 tel named[88689]: socket.c:1673: unexpected error: Feb 9 13:56:04 tel named[88689]: socket.c:1673: unexpected error: Feb 9 13:56:04 tel named[88689]: internal_accept(): accept() returned peer address family 0 (expected 2) Feb 9 13:56:04 tel named[88689]: internal_accept(): accept() returned peer address family 0 (expected 2) It doesn't indeed crash anymore. Upgrading time, then :-) -- Maarten
Re: Bug in Bind 9.1.0? [Summary]
For those of you keeping score, here are the (very unscientific) tallied repro reports so far on this issue: OS Yes No BSDi 4.01 BSD/OS 4.1 1 BSD/OS 4.2 1 Debian 2.2 3 FreeBSD 2.261 FreeBSD 4.1 2 FreeBSD 4.2-S 1 1 Linux 2.0 1 Linux 2.2 5 Linux 2.4 4 NetBSD 1.5 1 1 OpenBSD 2.5 1 OpenBSD 2.8 1 1 RedHat 6.2 2 RedHat 7.0 1 1 Slackware 7 2 Solaris 2.7 1 Solaris 7 1 These numbers include the reports below. Also, the numbers for the linux kernels reflect both reports where it was the only OS info given, as well as reports for which a distro and version were given. As mentioned below, Bind 9.1.1rc1 is now available, and may resolve this issue. More info on this is available at: http://www.isc.org/products/BIND/bind9-beta.html and the software itself is here: ftp://ftp.isc.org/isc/bind9/9.1.1rc1/bind-9.1.1rc1.tar.gz - OS: FreeBSD 2.2.6-RELEASE status: keeps on ticking OS: OpenBSD 2.5 status: crashes into oblivion in netaddr.c --- I have tried the following: nmap versions 2.00, 2.01, 2.02, 2.03, 2.04, 2.05, 2.06, 2.07, 2.08, 2.09, 2.10, 2.11, 2.12, 2.2-BETA1, 2.2-BETA3, 2.2-BETA4, and 2.50 all against BIND9.1.0 on FreeBSD 4.2-S (CVS and build date of 2/4/2001) and was unable to reproduce the problems. - From: matt sommer [EMAIL PROTECTED] nmap -sT -O -p 53 against bind9.1.0 built from source running on BSD/OS 4.1 and 4.2 is not affected. --- Normally configured/compiled BIND 9.1.0 on FreeBSD 4.1 , ran 'nmap O -sT -p 53' from another box and named kept running without a problem. Thanks. -RJR -- It seems that nmap -O -sT only kills it, if its not being used against the box'es own local loophole. Rather over an ethernet connection that adds some latency. This problem will be corrected in bind 9.1.1r1. Which was released last night. It was a problem I understand with debugging code still being in the production release. From: gabriel rosenkoetter [EMAIL PROTECTED] For what it's worth, I (finally) got bind9.1.0 to build from source statically on my system, and am happily running it now. Details: uriel:~# uname -mv NetBSD 1.5 (URIEL) #0: Thu Jan 25 15:27:28 EST 2001 [EMAIL PROTECTED]:/usr/src/sys/arch/macppc/compile/URIEL macppc Built like this: export CFLAGS='-O2 -static' ./configure --disable-threads --with-ssl=/usr/pkg [NetBSD has no reliable pthreads library and I only have a single processor anyhow; I felt like using the NetBSD OpenSSL port.] make nmap -sT -O against this system has absolutely no adverse affect. If NetBSD's got problems, they are either introduced by the pthreads library you use (ISC seems to recommend pkgsrc/devel/unproven-pthreads version 0.17 or later), or by NetBSD patches. (Moderator, I'm presuming you'll either include this in your next summary, or just ignore it. Either way is fine by me, as is clipping the above for a summary.) ~ g r @ eclipsed.net Ben Greenbaum Director of Site Content SecurityFocus http://www.securityfocus.com
Re: Bug in Bind 9.1.0?
Hi, After two days of recieving comments on my original posting and doing some testing, here's a summary: * The 'bug' seems to manifest itself randomly. Named on my machine crashes maybe 1 in 5 tries. This might explain why relatively few people were able to reproduce it. * Running nmap without any options at all can crash it; no need for '-O -St' or somesuch. * Nessus was reported by someone to have the same effect. * Besides Free- Open- and NetBSD folks, some Linux users with various kernels confirmed my findings as well. I believe ISC is still investigating this. Haven't heard from the FreeBSD people yet, altough they were the first I reported this to... -- Maarten 'Facts are stupid things!' said the man in control of the nukes.
Re: Bug in Bind 9.1.0? [Summary]
More repro reports. If no credit is given it is because the report was emailed to me and not the list, and I don't want to get anybody in trouble... --- I have tried nmap -O -sT -p 53 against a few hosts under my thumbs: the most hosts are Linux 2.2 but one FreeBSD 4.1 machine. All hosts run BIND-9.1.0. None was vulberable. From: Marcelo Bartsch [EMAIL PROTECTED] nmap O -sT -p 53 against bind 9.1.0 on solaris 2.7 make no damage, bind keep running. -- From: Ari Gordon-Schlosberg [EMAIL PROTECTED] RedHat 6.2, with the stock 2.2.14-5 kernel, Bind 9.1.0 built with './configure ; make ; make install' doesn't appear to be vulnerable. However, one thing confused me: The initial report said the command was 'nmap O -sT". That's not a legal nmap command. Was it supposed to 'nmap -O'? --- From: Richard Lindahl [EMAIL PROTECTED] I am running OpenBSD 2.8 on old AMD machine along with bind-9.1.0, and I am not experiencing any problems. The nmap -O -sT scan did not crash named for me. Maybe I am just lucky, or OpenBSD 2.8 i386 isnt vulnerable in this case ? - From: Jerry Walsh [EMAIL PROTECTED] I could reproduce this on OpenBSD 2.6 running Bind 9.1 and nmap V. 2.53 using: nmap -O -sT -p 53 foo.nameserver.com it crashed named everytime. And now you wonder why there's a ``keep-running'' script in the bin directory ;) -- From: "Maarten Van Horenbeeck" [EMAIL PROTECTED] No problems on the following systems: RedHat 6.2 standard install, bind-9.1.0 built from tarball Debian 2.2 standard install, bind-9.1.0 built from tarball Slackware 7, standard install, bind-9.1.0 built from tarball Kernel on all of this boxes is 2.2.17 for RedHat Debian, 2.4 on the Slackware-machine. --- From: "Branden R. Williams" [EMAIL PROTECTED] On an upgraded RedHat Linux 7.0 system with a compiled version of Bind 9.1.0, the nmap causes a crash. Here is what is in the logs. Feb 7 09:21:15 XX named[223]: connection.c:420: INSIST(sent_bytes == connection-out_bytes sent_bytes == isc_bufferlist_usedcount(bufferlist)) failed Feb 7 09:21:15 XX named[223]: exiting (due to assertion failure) Ben Greenbaum Director of Site Content SecurityFocus http://www.securityfocus.com
Re: Bug in Bind 9.1.0? [Summary]
This appears to not be as big a problem as it might have seemed, based
on the original report.
---
From: Jonas Thambert [EMAIL PROTECTED]
I wasnt able to replicate this error on a
fully patched RH 7.0 with BIND 9.1.0.
--
From: Stephen Clouse [EMAIL PROTECTED]
No effect on bind-9.1.0 built from source on linux (slackware-7.0, kernel
2.4.0).
---
From: Ian Gulliver [EMAIL PROTECTED]
I can't reproduce this using bind 9.1.0 on Linux 2.2.16/glibc 2.1.3 against
nmap 2.54BETA1. The source line listed would trigger if a socket family
other than AF_INET or AF_INET6 was being used. A quick grep through the
nmap source, however, shows nothing other than AF_INET passed to socket().
From: "Smith, John" [EMAIL PROTECTED]
I cannot duplicate this with Bind 9.1.0 running on a Solaris 7 box.
The Bind install is plain vanilla (configure, make, make install).
From: Phil Brutsche [EMAIL PROTECTED]
I haven't been able to reproduce this so far.
I'm using BIND 9.1.0 on Debian "potato", with Linux kernel 2.4.0, and nmap
2.53 to scan the server.
Hrm... looking at the source, I think there may be other issues with your
crash. From lib/isc/netaddr.c (offending INSIST(0) is underlined):
void
isc_netaddr_fromsockaddr(isc_netaddr_t *t, const isc_sockaddr_t *s) {
int family = s-type.sa.sa_family;
t-family = family;
switch (family) {
case AF_INET:
t-type.in = s-type.sin.sin_addr;
break;
case AF_INET6:
memcpy(t-type.in6, s-type.sin6.sin6_addr, 16);
break;
default:
INSIST(0);
^
}
}
--
From: Lucian Hudin [EMAIL PROTECTED]
the "problem" lies in file netaddr.c in bind 9.1.0 , line 231 with
"INSIST(0);"
this is not a bug, imho. You can compile named without asserts.
(#define ISC_CHECK_NONE in include/isc/assertions.h).
void
isc_netaddr_fromsockaddr(isc_netaddr_t *t, const isc_sockaddr_t *s) {
int family = s-type.sa.sa_family;
t-family = family;
switch (family) {
case AF_INET:
t-type.in = s-type.sin.sin_addr;
break;
case AF_INET6:
memcpy(t-type.in6, s-type.sin6.sin6_addr, 16);
break;
default:
INSIST(0);
}
}
searching for INSIST in source code tree also reveals this :
in "bin/tests/system/resolver/tests.sh"
"# If the server has the "INSIST(!external)" bug, this query will kill it.
$DIG +tcp www.example.com. a @10.53.0.1 -p 5300 /dev/null || status=1"
Ben Greenbaum
Director of Site Content
SecurityFocus
http://www.securityfocus.com
Re: Bug in Bind 9.1.0? [Summary]
More repro reports etc:
From: Stephen Oberther [EMAIL PROTECTED]
Hmmm..it doesn't have the same affect on our machine. i386 with Debian
2.2 running a home compiled BIND-9.1.0 Must be something in the
configuration of the NetBSD package.
--
From: Raptor [EMAIL PROTECTED]
I tried on this box:
narcissism:raptor {3} uname -a
OpenBSD narcissism 2.8 NARCISSISM#0 i386
;; ANSWER SECTION:
version.bind. 0S CHAOS TXT"9.1.0"
Named continued working perfectly. We installed it from source
distribution tarballs (non from ports) and it's running in a chrooted
environment.
--
From: "Bryan Paxton" [EMAIL PROTECTED]
Tested on Linux-2.4.2-pre1 (x86 SMP)| ISC BIND 9.1.0 | nmap version 2.12
Results: Didn't crash : )
---
From: Max Parke [EMAIL PROTECTED]
From [EMAIL PROTECTED] Tue Feb 6 21:40:07 2001
Feb 5 22:30:35 tel named[50956]: netaddr.c:231: INSIST(0) failed
Feb 5 22:30:35 tel named[50956]: exiting (due to assertion failure)
Feb 5 22:30:35 tel /kernel: pid 50956 (named), uid : exited on
signal 6
hrm.. no, mine is much different.
ugh. I hate BIND.
-lucas
Feb 6 21:05:55 x /usr/bind/named[56945]: client 123.123.123.150#1279:
error sending response: operation canceled
Feb 6 21:05:55 x /usr/bind/named[56945]: client 123.123.123.150#1280:
error sending response: operation canceled
Feb 6 21:05:55 x /usr/bind/named[56945]: client 123.123.123.151#1166:
error sending response: operation canceled
Feb 6 21:06:15 x last message repeated 211 times
Feb 6 21:06:16 x /usr/bind/named[56945]: client 10.1.1.2#137: error
sending response: operation canceled
Feb 6 21:06:45 x /usr/bind/named[56945]: mem.c:1404:
REQUIRE(mpctx-allocated == 0) failed
Feb 6 21:06:45 x /usr/bind/named[56945]: exiting (due to assertion
failure)
Feb 6 16:06:45 x /kernel: pid 56945 (named), uid 53: exited on signal
6
Ben Greenbaum
Director of Site Content
SecurityFocus
http://www.securityfocus.com
