[dns-operations] Concerns regarding the ICANN/IANA DNS vulnerability checker
simonw at zynet.net
Fri Aug 8 09:47:34 UTC 2008
On Friday 08 August 2008 09:52:38 Florian Weimer wrote:
> Here's an excerpt of
> | Assessment of CERT.UNI-STUTTGART.DE
> | Vulnerable.
> | The authoritative name servers for “CERT.UNI-STUTTGART.DE” are vulnerable
> | to cache poisoning. However, those providing recursive name servers have
> | unpredictable source ports so the risk is lowered, but not eliminated.
> | Name server IP Address Result
> | ARTEMIS.RUS.UNI-STUTTGART.DE 18.104.22.168 Is recursive, with source
> | port randomisation
> | DNS.CERT.UNI-STUTTGART.DE 22.214.171.124 Not recursive
> | DNS1.BELWUE.DE 126.96.36.199 Not recursive
> | DNS3.BELWUE.DE 188.8.131.52 Not recursive
> | SKYLLA.RUS.UNI-STUTTGART.DE 184.108.40.206 Not recursive
> The problem is that it's flat out wrong. Admittedly, 220.127.116.11 runs
> an open resolver for historical reasons. But this has no direct
> effect on the CERT.UNI-STUTTGART.DE zone because all glue is
> authoritatively known to 18.104.22.168, so there is no cache pollution
Except the glue for badguy645654.cert.uni-stuttgart.de which it doesn't know
yet. I don't know if it can be persuaded to cache it. Obviously anyone
controlling that probably has inappropriate access to cookies and other
security contexts. Are you sure it can't be persuaded to cache bad data for
zones underneath CERT.UNI-STUTTGART.DE?
The statement is true, the authoritative servers for that domain are
vulnerable to cache poisoning. They didn't state that the poisoning would
affect the zone they are authoritative for.
> The whole test is bogus anyway because publicly available recursive
> service is neither necessary nor sufficient for the presence of cache
> poisoning potential.
I believe it is a necessary condition of poisoning an authoritative server.
Do you have evidence of, or method to, poison an authoritative only server?
> Apart from that, it saddens me that ICANN joins the popular game of
> pushing random agendas using mostly unrelated security
> vulnerabilities. The apparent lack of understanding of DNS protocol
> issues worries me, too.
It may be this particular server is secure in it's current configuration
against poisoning of the current zones loaded, although it can of course be
used in DDoS attacks, and as a named server for spambots (to avoid detection
from ISPs who look for suspicious DNS requests). It may also be that
poisoning the cache on the box may undermine its operation as a DNS server,
if say it uses itself as a recursive name server to obtain zone data.
Either way the university is at best negligent in the running of its DNS
False positive - perhaps if your only threat model for DNS is Dan Kaminsky
powered script kiddie might make them look daft.
More information about the dns-operations