is there another hole in BIND?

[jsz () ramon bgu ac il (jsz)]

Unless it's something brand new and super unknown --
as I understand the current bind vulnerablity that Paul Vixie
mentioned here has nothing to do with DNS spoofing-via-altering-the-glue
records, although I was pointed out a few months ago, that a forward lookup
in gethostbyaddr() of 4.9.2 and prior versions was vulnerable to a quite
trivial DNS spoofing, the details are quite trivial:

if a "black hat" wants to get onto spoofed.boom.net and runs DNS for
foobar.net -- he just needs to alter an "A" record for spoofed.boom.net, 

add:

spoofed.boom.net        CNAME   some_of_his_sites.

some_of_his_sites.      A       [real ip # of some_of_his_sites goes here]
some_of_his_sites.      A       [ip # of spoofed.boom.net]

The reverse lookup code in bind_4.9.2 and prior, ie gethostbyaddr()
does NOT do a forward lookup on the result it gets. It's quite easy
to locate it in the sources of resolver, so if you added "pseudo" 
resolving modules to the libc, you're open to trivial DNS spoofing
attack. Thus rshd rlogind and mountd as well as ypservd just call 
gethostbyaddr() which gets the bogus address. I think Steve Bellovin
covered it pretty much in his paper. 

this is of course not new, and I think resolv+ has "anti-spoof" 
option, which is not on by default.

Supposedly bind 4.9.3 fixes this, but I have accidently removed the srcs 
of 4.9.3 one I had here, and couldn't locate them anywhere, on ftp.uu.net
it seems to be buried under some hidden directory, or something..

I was under impression that the brand new bug that Paul Vixie is working
on was related to the recent "Internet-wide Nameserver Problems" when
a site off of psi (I think ird.scitex.com -- wouldn't bet my life on it
though) claimed root responsibility for "in-addr.arpa" (thus acted as
Internet hostmaster) and as a result, it corrupted Internet root nameserver
database. So if anyone on the net redefines the "IN-ADDR.ARPA" resource record
on local nameserves, it'll cause reverse lookups to fall, and result of
this serious problem is hard to predict. 

My other guess was that: it's quite easy to kill off a named daemon with
a udp packet with an invalid length field, from remote site. 

But who knows, maybe this time it's something _really_ new with bind.


My 0.2 $

--Me