[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACYkhxjeyLYjSUzvMLAkTKQVKg9r5-aL+yv38jALZJTa=UGsfA@mail.gmail.com>
Date: Tue, 11 Feb 2014 22:28:35 +1100
From: Michael Samuel <mik@...net.net>
To: oss-security@...ts.openwall.com
Subject: Re: CVE Request New-djbdns: dnscache: potential cache poisoning
On 11 February 2014 17:54, P J P <ppandit@...hat.com> wrote:
> Upstream author's reply:
>
> > On Tuesday, 11 February 2014 4:28 AM, Frank Denis wrote:
> >
> > The shorter the TTL of a record is, the easier a cache can be poisoned.
> > It is when a record is NOT cached that spoofed authoritative replies
> > can be sent and get a chance to reach the resolver before the
> > legitimate one.
> >
> > As soon as a valid response is received, dnscache invalidates the state,
> > discarding further responses, even if these are valid.
>
This response doesn't address the original claim.
The author of the original link made the (probably true) claim that
requests could
be made to authoritative sources (records under the control of the attacker)
which would deliberately collide with results for some other domain such as
.com.
Since each bucket has a limit of 100 records, this would make it easier to
push
a record from the cache, giving the attacker another chance at spoofing a
reply
a little bit sooner. Each time this happened, the attacker would have just
under
1 in 2^32 chance of succeeding.
The simplest strategy for this would be to constantly send replies to a
specific
port with a specific ID, and waiting for the server to randomly use this
combination, in which case the attacker would surely beat the server.
The security flaw is in the DNS protocol, and (apart from protocol upgrade
fantasies) the only practical way to mitigate this is to have a pool of IP
addresses to initiate recursive requests from. Using siphash would make
this
attack slightly harder, but a large number of random names would presumably
have a similar effect for only slightly more traffic (how many buckets are
there?).
In short, the hashtable is not a DNS cache poisoning protection mechanism,
DNS
cache is supposed to expire or be pushed out by "hotter" records, so I'd
say it's not
a vulnerability. I'd still recommend switching hash algorithms.
Regards,
Michael
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
