Date: Fri, 10 Nov 2000 19:35:12 +0800 From: Greg Lehey <grog@lemis.com> To: Doug Barton <DougB@FreeBSD.org> Cc: heckfordj@psi-domain.co.uk, freebsd-isp@FreeBSD.org, =?iso-8859-1?Q?Mathias_K=F6rber?= <Mathias.Koerber@nominum.com>, FreeBSD Committers <cvs-committers@FreeBSD.org> Subject: Re: BIND 8.2.2-P5 Possible DOS Message-ID: <20001110193512.I1686@sydney.worldwide.lemis.com> In-Reply-To: <3A0AE465.7825FF37@FreeBSD.org>; from DougB@FreeBSD.ORG on Thu, Nov 09, 2000 at 09:52:37AM -0800 References: <00110819041604.01782@freefire.psi-domain.co.uk> <3A0AE465.7825FF37@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
[originally sent to -ISP]
On Thursday, 9 November 2000 at 9:52:37 -0800, Doug Barton wrote:
> Jamie Heckford wrote:
>>
>> Verified this earlier... make sure your nameservers are configured correctly!!
>>
>> Nov 8 19:00:47 atlas named-xfer[78583]: [x.x.x.x] no SOA found for xxx, SOA
>> query got rcode 3, aa 1, ancount 0, auc ount 1
>>
>> Nov 8 19:01:05 atlas named[276]: unsupported XFR (type ZXFR) of "xxx" (IN) to
>> [x.x.x.x].1368 Nov 8 19:01:21 atlas named[276]: d_rcnt-- == 0
>>
>> Nov 8 19:01:21 atlas /kernel: pid 276 (named), uid 53: exited on signal 6
>>
>> Nov 8 19:01:21 atlas named[276]: d_rcnt-- == 0
>>
>> ---------- Forwarded Message ----------
>> Subject: BIND 8.2.2-P5 Possible DOS
>> Date: Tue, 7 Nov 2000 13:40:49 +0100
>> From: "Fabio Pietrosanti (naif)" <fabio@TELEMAIL.IT>
>>
>> Hi,
>> playing with bind and ZXFR feature ( zone transfer compressed with a possible insecure
>> execlp("gzip", "gzip", NULL); ), i discovered a Denial Of Service against Bind 8.2.2-P5 .
>>
>> By default Bind 8.2.2-P5 it's not compiled with ZXFR support unless you define it with #define BIND_ZXFR
>> so it will refuse any ZXFR transfer, because it doesn't support it.
>> But now what appens? Look here...
>>
>> ################################
>> zone to transfer: zone.pippo.com
>> dns server: dns.pippo.com 192.168.1.1
>> me: naif.gatesux.com 10.10.10.10
>> I send a Zone Trasnfer request using "-Z" switch with means that i wish to use ZXFR.
>> dns.pippo.com does'nt support ZXFR and have "allow-transfer{}" not configured, so everyone
>> could ask him for *.zone.pippo.com ...
>>
>> <naif@naif> [~/bind/src822p5/bin/named-xfer] $ ./named-xfer -z zone.pippo.com -d 9 -f pics -Z dns.pippo.com
>> named-xfer[29297]: send AXFR query 0 to 192.168.1.1
>> named-xfer[29297]: premature EOF, fetching "zone.pippo.com"
>>
>> On the server's log:
>> Nov 7 11:19:09 dns.pippo.com: named[188510]: approved ZXFR from [10.10.10.10].2284 for "zone.pippo.com"
>> Nov 7 11:19:09 dns.pippo.com: named[188510]: unsupported XFR (type ZXFR) of "zone.pippo.com" (IN) to [10.10.10.10].2284
>>
>> Then the server "*** CRASHED ***" .
>>
>> I should assume that bind 8.2.2-P5 it's vulnerable ( Please someone test and confirm this kind of dos)
>> and bind-9.0.0 has no support for ZXFR .
>>
>> <naif@naif> [~/bind] $ find src822p5/ -type f -exec grep -i zxfr \{\} ';' | wc -l
>> 234
>> <naif@naif> [~/bind] $ find bind-9.0.0/ -type f -exec grep -i zxfr \{\} ';' | wc -l
>> 0
>>
>> A lot of DNS Server are misconfigured, and allow zone-transfer to any, so they are dossable...
>
> The latest versions of -current and -stable both have BIND 8.2.3-T6b,
> which has this, and several other nasties fixed. I've been running that
> version of BIND on a highly visible, heavily loaded public ns for
> several months without problems.
I'm currently in a Singapore Linux User group meeting, and we were
discussing this matter. Mathias Körber of Nominum is of the opinion
that it's wrong to use BIND 8.2.3-T6b in -STABLE. He also doubts that
this particular bug is fixed in this version. I don't have enough
knowledge of the issues to comment. Does anybody else?
Greg
--
Finger grog@lemis.com for PGP public key
See complete headers for address and phone numbers
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-isp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20001110193512.I1686>