[dns-operations] Concerns regarding the ICANN/IANA DNS vulnerability checker

Simon Waters 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 
<http://recursive.iana.org/?query=cert.uni-stuttgart.de>:
> | 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 129.69.1.28    Is recursive, with source
> | port randomisation
> | DNS.CERT.UNI-STUTTGART.DE    141.58.89.50   Not recursive
> | DNS1.BELWUE.DE               129.143.2.10   Not recursive
> | DNS3.BELWUE.DE               131.246.119.18 Not recursive
> | SKYLLA.RUS.UNI-STUTTGART.DE  141.58.231.9   Not recursive
>
> The problem is that it's flat out wrong.  Admittedly, 129.69.1.28 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 129.69.1.28, so there is no cache pollution
> issue.

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 
operations.

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 mailing list