BIND's vulnerability to packet forgery

[Michael Kjorling]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

This will be my last post on the subject unless I am personally
attacked, which for the best of everyone I hope will not happen.


On Jul 31 2001 00:59 -0000, D. J. Bernstein wrote:

> BIND company employee Jim Reid writes:
> > You said that BIND9 used /dev/random for random query ids. The code
> > snippet above clearly disproves that.
>
> BIND 9 uses /dev/random for query IDs, through a convoluted chain of
> functions including isc_entropy_usebestsource(), reseed_lfsr(), and
> dns_randomid(). Other people have already explained that you aren't
> reading the code correctly.

`usebestsource' sounds like a place where you could easily extend it
with additional random sources. Why not hook up a Geiger counter to
your DNS servers, so that you get truly random numbers?


>   [ random() is easily predictable ]
> > Indeed. So is any other computer-generated "random" number process
> > unless it's driven off something truly random like radioactive decay.
>
> Wrong again. Cryptographically strong generators start from a short
> secret, typically 256 bits, and are unpredictable to everyone who
> doesn't know the secret.

First of all I wouldn't consider a 256-bit secret to be a short one -
it's a fairly long one. (PGP, which needs pretty much military
security and way beyond, uses 512 bits and a complicated system of
hashing and randomization for its PRNG. I belive it's an ANSI
standard, but don't remember the number.)

But that set aside, you are tripping yourself. Where is the secret
going to come from _in the first place_? Somehow it has to be
generated. Anyone attacking any system is likely to go at the weakest
link; if a secret for a strong PRNG is generated using a
(cryptographically) weak PRNG, then the entire system is going to be
weak. IIRC, English language contains about 1.7 bits of entropy per
character - random keystrokes are better, but not much so. There has
been a lot of research put into the field of generating reasonably
non-predictable random numbers on predictable, finite-state machines
(e.g., computers).

A chain is never stronger than its weakest link. That holds especially
true in cryptography - and in encryption software, the actual reason
for the security hole can be very far from the encryption code.

Also, Bruce Schneier (who is pretty knowledgeable when it comes to
cryptography I have heard and is the inventor of both Blowfish and
Twofish) said that while a computer can be in a large number of
possible states, it is still a finite number. Any finite number space
can, by definition, be searched through (this is my addition). It
might take time, but it is possible. You have a very maximum of 65535
possible outputs.

Whether or not though - how is that 256-bit secret generated in a
truly random way?


> > IIRC Mr. Turing had something to say about that.
>
> In fact, what Turing said was that he had a cryptographically strong
> generator: ``I have set up on the Manchester computer a small programme
> using only 1000 units of storage, whereby the machine supplied with one
> sixteen figure number replies with another within two seconds. I would
> defy anyone to learn from these replies sufficient about the programme
> to be able to predict any replies to untried values.''

But given the design specifications and plans for that machine, maybe
it is easier? That is what you've got when it comes to open source
software.


> > > Randomizing the port number makes a huge difference in the cost of a
> > > forgery for blind attackers---i.e., most attackers on the Internet.
> > Anyone mounting a serious attack on the DNS is unlikely to be blind.
>
> If you believe that, why don't you rip the useless ID randomization code
> out of BIND? Of course, you'll have to find the code first.

Did he ever say it was useless? Random query IDs help prevent
collisions between users on the same system, for example - this is
especially important if you are running a multi-homed system of some
kind, but attention should be paid even if you are only sending
queries on one interface.


> > 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.
>
> You are talking about a fantasy world where .com registrants give DNSSEC
> keys to VeriSign, which signs and distributes those keys. That isn't
> happening now, and it isn't going to happen in the foreseeable future.

So how is 'more random' query IDs going to help against someone
modifying a DNS packet as it passes by?


Michael Kjörling

- -- 
Michael Kjörling - michael at kjorling.com - PGP: 8A70E33E
Manager Wolf.COM -- Programmer -- Network Administrator
"We must be the change we wish to see" (Mahatma Gandhi)

^..^     Support the wolves in Norway -- go to     ^..^
 \/   http://home.no.net/ulvelist/protest_int.htm   \/

***** Please only send me emails which concern me *****

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE7Zg0mKqN7/Ypw4z4RAmxxAJ4tZFIDrWenEe4y6hS8pjpuwNUBFACdGml2
x0TsooyghW3qUkHAePt87mE=
=4Zm8
-----END PGP SIGNATURE-----