Date: Wed, 31 Oct 2007 14:44:35 +0100
From: Shane Kerr <Shane_Kerr@....org>
To: bugtraq@...urityfocus.com
Subject: Re: Comments re ISC's announcement on bind9 security

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

Sir or Madam,

> I found this ISC announcement quite amusing:
> http://www.isc.org/index.pl?/sw/bind/docs/response_transaction_id_issues.php
> It's a text published by ISC as a follow up to the bind9 predictable id saga.
>
> Particularly the following statement is funny, and shows complete lack
> of understanding of the terminology and of the problem space:
>
> 'ISC would like to assure the Internet community that this is much
> less an issue of using "extremely weak crypto" as it has been
> described, than the use of a random number generator that did not
> provide sufficient randomness.'
>
> My understanding is that they used a pseudo random number generator in
> bind9, and when you use a pseudo random number generator (whose
> sequence in this case is predictable after observing about a dozen
> outputs) instead of a strong cryptographic algorithm whose sequence
> cannot be practically predictable, how do you call this? right -
> "extremely weak crypto".

There seem to be two ideas you are presenting here, both intended to imply that
the developers at ISC are technically incompetent:

1. Using a pseudo-random number generator should be called "crypto".

2. The particular pseudo-random number generator that BIND 9 now uses is a poor
   choice.


I think the first issue is not as important as the second issue, because it is
mostly a semantic debate. My own take on it is that "crypto" implies that
information is hidden in some way. Not all security-related technology is
cryptography. For instance, putting per-user limits on resources prevents
certain kinds of denial-of-service attacks, but it is certainly not "crypto".

Because a lot of techniques in cryptography require good random numbers, it has
been widely studied by cryptographers. Therefore if you want a good
pseudo-random number generator, it is probably a good idea to see what the state
of the art in the cryptography field is. But random number generation is not
"crypto" any more than using a series of bit shift and XOR operations is crypto.


The second issue is much more important.

Let me begin by saying that as far as I or anyone else at ISC knows, the current
BIND 9 implementation does not have any exploitable weakness in the transaction
identifier generation. If you or anyone knows otherwise, please let us know and
we'll look into it.

Having said that, the history of this exploit from our side goes something like
this:

- - Amit Klein sent us a draft document about a weakness in the linear shift
  register (LSR) generator used in BIND 9.

- - A few of us had a look, and sure enough, the LSR was badly broken for this
  purpose.

- - After some discussion, we opted to forward port the BIND 8 code rather than
  invent a new solution to the problem.

- - Shortly after, Amit Klein sent us a draft document about a much, much worse
  weakness in the BIND 8 code, which was now in BIND 9. He noted that BIND 9 did
  not seem to be exploitable, but maybe theoretically it was.

- - We looked at this, and sure enough, BIND 8's query ID generator was badly
  broken.

- - Since BIND 8 was almost at end of life (it is now), we opted to remove the
  generator code and require a strong random number generator for this. AIUI,
  the arc4random() function *has* been developed by security experts, including
  cryptographers, so it should be Good Enough(tm) for a 16-bit value in software
  that nobody should use.

- - Since there was no known exploit for the BIND 9 code, we decided to leave the
  code alone, with the idea to put something harder to predict at a later time.

So, I think our main mistake here was using the BIND 8 code rather than
developing a solution that was easier to understand (and analyze), based on best
current practices from pseudo-random number generators. But, since the code is
sound, I think we are on solid ground with the public statement we made.

> The irony is that statement is found in a text intended to instill
> trust and reassure the bind9 users that ISC digs security...

We do "dig" security. I think the track record for BIND 9 shows that.

- --
Shane Kerr
ISC
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHKIa/MsfZxBO4kbQRAj7ZAJ43nkS/zLlz8qudDlzhmUPB+mizbQCfR8EZ
v0qZqJd+COMDQ38QD/uanto=
=lO6c
-----END PGP SIGNATURE-----

Powered by blists - more mailing lists