Yeah, I think we're thinking along the same lines. You can do exactly three
things to improve your odds in a blind spoofing race:
1. Increase the transmission rate of your guesses - neither interesting nor
fixable
2. Increase the accuracy of your guesses - this probably only works vs
individual implementations, unless the DNS protocol provides a way to
deplete the entropy pool from which TXID's are selected. I'm not ruling it
out just yet, but it doesn't seem like the most fertile ground for mass
ownage.
3. Increase the duration of the attack window - i.e., incapacitate or stall
the legitimate responder.
My money is on #3.
Supplemental note to Halvar & everybody else who has said, in effect, "this
is why SSL was invented" -- there's more to internet security than the route
from your computer to your online bank. Have you thought about what this
bug implies for NTLM? Or every virgin OS installation on the planet? Or
Google's entire business model?
shutting up now,
pty
On Sat, Jul 12, 2008 at 10:24 PM, Brandon Enright <bmenrigh_at_ucsd.edu> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Sat, 12 Jul 2008 21:03:53 +0200 or thereabouts Parity
> <pty.err_at_gmail.com> wrote:
>
> > My totally uninformed speculation is worth way less than $0.02, but -
> >
> > Dan says he discovered the attack by accident. Mapping a sequence of
> > TXID's into a rainbow table is not something one does on a whim.
> > Moreover, if the attack you just proposed works against TXID's, then
> > it ought to just as likely work against source ports as well.
>
> Agreed. I don't think this is a PRNG break at all. Here's a few
> reasons why:
>
> * Dan claims the flaw is in the protocol and generating random TXIDs
> isn't enough (yeah, we all know 16 bits isn't enough entropy).
>
> * Dozens of DNS vendors have "fixed" their code on this one. A break
> of dozens of different PRNGs via "rainbow tables" or whatever would be
> _amazing_. An attack like this would likely break TCP ISN generators
> too.
>
> * None of the "fixes" have been to improve randomness. A nearly random
> TXID (by whatever magic algorithm generated it) would make any rainbow
> table computationaly infeasible.
>
> * We've known for a long time that it is easy to send 64k packets, one
> for each TXID. The trouble has always been in racing the correctly
> responding system to the right answer (or DoS it so that it can't
> respond).
>
> >
> > For my money, if he says he discovered it by accident, then Dan means
> > to say that he was looking at a graph of some sort at the time.
> >
> > pty
> >
>
> Dan has my interest really peaked on this one. I think Dan has
> discovered a way to invalidate the remotely responding system so that
> you can try all TXIDs and not have it be a race.
>
> I think "by accident" means that Dan discovered some way to get the
> victim into a state where the correctly responding server is taken
> completely out of the picture so that you can just flood all the TXIDs.
>
> If you have to guess port and TXID, instead of having to flood on
> average, 32k, you'd have to flood 2B.
>
> Brandon
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.9 (GNU/Linux)
>
> iEYEARECAAYFAkh5EvwACgkQqaGPzAsl94K+qQCgnDdDbMtoRQdrkH+eJxNlMtr8
> TTYAnAuMKQbYX4gsJnogVsts3rxA8sBO
> =Oumc
> -----END PGP SIGNATURE-----
>
_______________________________________________
Dailydave mailing list
Dailydave_at_lists.immunitysec.com
http://lists.immunitysec.com/mailman/listinfo/dailydave
Received on Jul 12 2008
Intro
