BIND's vulnerability to packet forgery
D. J. Bernstein
BIND company employee Jim Reid writes:
> The "packet forgery" you refer to applies to verifying and signing DNS
> data with DNSSEC.
Wrong. As discussed in http://cr.yp.to/djbdns/forgery.html, the current
reality is that DNSSEC does nothing to prevent forgeries. I'm talking
about the protections that _do_ stop some attacks right now:
(1) cryptographic randomization of DNS query IDs and
(2) cryptographic randomization of the UDP port for each query.
Apparently BIND doesn't do #1 without /dev/random, and it doesn't do #2
at all. In contrast, djbdns does both #1 and #2 automatically.
> The reason for the irony is that your DNS software doesn't support
> DNSSEC or Secure Dynamic Update at all.
My software supports secure outage-free upates. Security is provided by
standard external tools, typically IPSEC or ssh.
---Dan
Jim Reid
djb> BIND company employee Jim Reid writes:
>> The "packet forgery" you refer to applies to verifying and
>> signing DNS data with DNSSEC.
djb> Wrong. As discussed in http://cr.yp.to/djbdns/forgery.html,
djb> the current reality is that DNSSEC does nothing to prevent
djb> forgeries.
Really? When were RSA and DSA broken?
djb> I'm talking about the protections that _do_ stop
djb> some attacks right now:
djb> (1) cryptographic randomization of DNS query IDs and
djb> (2) cryptographic randomization of the UDP port for each query.
And neither of these things is a significant improvement. They barely
raise the barrier for an attacker. Both the port number and query id
are known when the query leaves the server, so responding with a fake
reply is trivial. Or don't you classify that fake reply as "forgery"?
djb> Apparently BIND doesn't do #1 without /dev/random,
Wrong. From setup_lookup():
lookup->sendmsg->id = (unsigned short)(random() & 0xFFFF);
Last time I looked random() was not the same as /dev/random. Now some
might argue that random() isn't random enough. Even so it's probably
good enough as an entropy source for the purpose it gets used for
here.
djb> and it doesn't do #2 at all. In contrast, djbdns does both #1
and #2
djb> automatically.
So what? Randomising the port number for each query achieves precisely
nothing. Apart from making the OS and name server do more work by
explicitly naming that socket; an extra system call per query. An
attacker can still see that query in all its glory and fake a reply to
it.
>> The reason for the irony is that your DNS software doesn't
>> support DNSSEC or Secure Dynamic Update at all.
djb> My software supports secure outage-free upates. Security is
djb> provided by standard external tools, typically IPSEC or ssh.
Perhaps: for your definition of security. How does your code detect a
forged or tampered reply? Well if the reply was signed and your code
supported DNSSEC, it could do that. But it doesn't. So it can't.
Michael Kjorling
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I don't want to involve in flame wars, but I have to reply to this
since it is so obviously wrong.
First your point #1 - "cryptographic randomization of DNS query IDs".
Let me tell you that I seriously doubt that /dev/random is a
cryptographically secure PRNG (pseudo-random number generator), on any
platform. Relying on it for anything but a few bits of entropy every
few hours, or less, would probably be a VERY bad thing to do. Besides,
I fail to see how this would help against attacks? Query IDs are used
to match queries with their respective answers - so unless you can
guess exactly when a query with a specific ID is being asked, you will
be having a hard time spoofing the response. Or do you mean flooding a
DNS client with responses until one eventually matches?
(2) - same thing here. You are talking about cryptographically secure
random numbers generated by /dev/random when /dev/random is inherently
not adapted for that kind of work. Period. I might be wrong on some
very specific platforms - one that comes to my mind is OpenBSD which
has a record of being secure. But that would be the exception. And
again, how would you expect a "more random" source port would help
security? Any system connected to the Internet today should be behind
a firewall; those who aren't probably have bigger problems than
spoofed DNS responses. Most firewalls are stateful - they allow the
query to go out, then remember the port and IP quads that were used
and allow responses back in. Do you mean that someone is going to run
the entire IP space and probable port range (say 1024-5000) down the
throat of someone hoping to get one right?
You have been bashing DNSSEC and TSIG because they are not yet widely
deployed. Yet, you bring up completely unrelated technologies like SSH
(which doesn't have to do with DNS at all!) - and how many have
implemented IPsec on a large scale so far? I don't have numbers but I
dare say not many.
What cryptographically secure PRNG are you using in djbdns? Not that I
think most people here care, but it would be interesting for me to
know.
Michael Kjörling
PS. A note to the moderator - if my post is too harsh in wording, feel
free to drop it. I won't be offended.
On Jul 29 2001 11:31 -0000, D. J. Bernstein wrote:
> BIND company employee Jim Reid writes:
> > The "packet forgery" you refer to applies to verifying and signing DNS
> > data with DNSSEC.
>
> Wrong. As discussed in http://cr.yp.to/djbdns/forgery.html, the current
> reality is that DNSSEC does nothing to prevent forgeries. I'm talking
> about the protections that _do_ stop some attacks right now:
>
> (1) cryptographic randomization of DNS query IDs and
> (2) cryptographic randomization of the UDP port for each query.
>
> Apparently BIND doesn't do #1 without /dev/random, and it doesn't do #2
> at all. In contrast, djbdns does both #1 and #2 automatically.
>
> > The reason for the irony is that your DNS software doesn't support
> > DNSSEC or Secure Dynamic Update at all.
>
> My software supports secure outage-free upates. Security is provided by
> standard external tools, typically IPSEC or ssh.
>
> ---Dan
- --
Michael Kjörling - mic...@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
iD8DBQE7ZAqvKqN7/Ypw4z4RAkOCAKC9rVsCm2Pyoq0ytm7OpaYgzlXFhgCgh8b0
tbt3g/g9bPUgZ4GvKffa27k=
=QvQT
-----END PGP SIGNATURE-----
D. J. Bernstein
Jim Reid writes:
> Wrong. From setup_lookup():
> lookup->sendmsg->id = (unsigned short)(random() & 0xFFFF);
Wrong. I said ``cryptographic randomization.'' The output of random() is
not cryptographically secure. In fact, it is quite easily predictable.
This is a standard exercise in first-semester cryptography courses.
> Randomising the port number for each query achieves precisely nothing.
Wrong. Randomizing the port number makes a huge difference in the cost
of a forgery for blind attackers---i.e., most attackers on the Internet.
Here's the picture:
normal colliding sniffing
blind attack blind attack attack
------------ ------------ --------
nothing 1 1 1
ID (BIND) 65536 256 1
ID+port (djbdns) 4227727360 65020 1
It's funny that the BIND company has gone to so much effort to move from
the first line to the second, but now pooh-poohs the third line.
> > Wrong. As discussed in http://cr.yp.to/djbdns/forgery.html, the
> > current reality is that DNSSEC does nothing to prevent forgeries.
> Really? When were RSA and DSA broken?
Do you think that ``RSA'' is a magic word that makes security problems
disappear? Withotu a central key distribution system---a system that
doesn't exist now and won't exist for the foreseeable future---DNSSEC
doesn't stop forgeries.
---Dan
Paul Vixie
> It's funny that the BIND company has gone to so much effort to move from
> the first line to the second, but now pooh-poohs the third line.
Patches welcome. (The current random query ID stuff came, I think, from Theo.)
Mark Mentovai
> djb> Apparently BIND doesn't do #1 without /dev/random,
>Wrong. From setup_lookup():
>
> lookup->sendmsg->id = (unsigned short)(random() & 0xFFFF);
>
>might argue that random() isn't random enough. Even so it's probably
>good enough as an entropy source for the purpose it gets used for
>here.
Better than that: setup_lookup() is part of dig (, host, nslookup). The
nameserver itself uses different code to form queries, and the query ID
is significantly more random. /dev/random is still not required.
> djb> and it doesn't do #2 at all. In contrast, djbdns does both #1
>and #2
> djb> automatically.
>
>So what? Randomising the port number for each query achieves precisely
>nothing. Apart from making the OS and name server do more work by
>explicitly naming that socket; an extra system call per query. An
>attacker can still see that query in all its glory and fake a reply to
>it.
With a static port number, there is one less variable for an attacker
without access to the wire to guess. There are still many others,
including the query ID, which as we've established is indeed random.
If your attacker has unrestricted access to the wire, then you've got
more serious problems than your DNS implementation to work out, and no
amount of randomizing source ports or query IDs will eliminate this type
of attack.
Mark
Jim Reid
>> 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?
Robert Wood
> Do you think that ``RSA'' is a magic word that makes security problems
> disappear? Withotu a central key distribution system---a system that
> doesn't exist now and won't exist for the foreseeable future---DNSSEC
> doesn't stop forgeries.
What's the official word from Network Solutions or whoever's supposed
to be doing this? Is there any indication that someone is working on
it? Who has the ultimate responsibility for it?
D. J. Bernstein
BIND company employee Jim Reid writes:
> 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.
[ 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.
> 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.''
> > 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.
> 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.
---Dan
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 - mic...@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-----