BIND's vulnerability to packet forgery

Jim Reid jim at rfc1035.com
Mon Jul 30 15:18:50 UTC 2001


>>>>> "djb" == D J Bernstein <75628121832146-bind at sublist.cr.yp.to> writes:

    >> Jim Reid writes:
    >> Wrong. From setup_lookup():
    lookup-> sendmsg->id = (unsigned short)(random() & 0xFFFF);

    djb> Wrong. I said ``cryptographic randomization.''

You said that BIND9 used /dev/random for random query ids. The code
snippet above clearly disproves that. To refresh your memory, you
claimed that /dev/random had to be copied to a chroot jail for BIND
even though it had already been shown to be unnecessary unless Secure
Dynamic Update was used.

    djb> random() is not cryptographically secure. In fact, it is
    djb> quite easily predictable.  This is a standard exercise in
    djb> first-semester cryptography courses.

Indeed. So is any other computer-generated "random" number process
unless it's driven off something truly random like radioactive decay.
Some of these processes might be easier or harder to predict than
random() (or /dev/random) but they will be predictable. IIRC
Mr. Turing had something to say about that.

    >> Randomising the port number for each query achieves precisely
    >> nothing.

    djb> Wrong. Randomizing the port number makes a huge difference in
    djb> the cost of a forgery for blind attackers---i.e., most
    djb> attackers on the Internet.

Anyone mounting a serious attack on the DNS is unlikely to be
blind. Script kiddies who don't know any better might try blind
attacks. A serious attacker is unlikely to waste time and effort on
something as unproductive. The most realistic attack will be to tamper
with the contents of a query response as it goes past. By then, the
attacker will know the source and destination IP addresses and port
numbers of the queries that are being made as well as the query
id. Randomising the port and and query id is moot by then. You're
deluding yourself if you don't make that assumption. [Just like in
crypto, you assume the attacker knows everything except the key: if
it's the key that is to be broken of course.]

Now Secure DNS prevents faked answers because the DNS packets are
signed. ie It can be proven an answer for www.amazon.com *really* does
come from a name server for amazon.com and the answer hasn't been
tampered with since it left that server.

So to repeat my question, what does your software do to protect itself
(and its users) from faked or corrupted query reponses?


More information about the bind-users mailing list