Vulnerability to cache poisoning -- the rest of the solution

James Pratt jpratt at norwich.edu
Fri Jul 11 21:19:22 UTC 2008


> -----Original Message-----
> From: bind-users-bounce at isc.org [mailto:bind-users-bounce at isc.org] On
Behalf Of
> Kevin Darcy
> Sent: Friday, July 11, 2008 4:35 PM
> To: bind-users at isc.org
> Subject: Re: Vulnerability to cache poisoning -- the rest of the
solution
> 
> > If any client, inside *or* outside your network, uses your server
for
> > recursion, then your server is a potential target for this kind of
attack.
> > And if it hasn't been updated with the patch, the attack may well
succeed.
> >
> >
> Let's be clear here. The problem is *response*forgery*.
> 
> The fact that the forged responses may get into the cache and affect
> future lookups only *amplifies* the problem. But even devices that
don't
> cache *at*all* (e.g. so-called "DNS proxies") can be affected by this
issue.
> 
> There have been genuine "cache poisoning" issues in the past (e.g.
> unrelated, malicious data in the Authority or Additional sections of a
> response getting into caches), but this isn't one of them.
> 
> Frankly, the media, and even some of the technical experts quoted in
the
> media, have been doing a disservice, in my opinion, by constantly
> describing this issue only as "cache poisoning".
> 
> Terminology matters.
> 
> - Kevin
> 


I would agree about the media. Thank you very much for clarifying those
important bits. 

So the big question really is - Is the security of the internet in
*real* big trouble after blackhat, unless dnssec is implemented
basically everywhere?

I understand it's great to have your own rr's secured, but it probably
doesn't  help much at all internally if you *have to* give your lan/wan
clients recursion, correct? 

Regards,
jamie




More information about the bind-users mailing list