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? [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]
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
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