[dns-operations] adns vuln posted

[Robert Edmonds]

Paul Vixie wrote:
> at <http://downloads.securityfocus.com/vulnerabilities/exploits/30131_zmda.c>
> we see that the "adns" asynchronous stub resolver has enough of a following to
> deserve its own exploit.  anybody know the author?  this oughta get fixed.

i maintain adns in debian.  ian jackson is the author; here is his
response when i asked him earlier about this issue:

Robert Edmonds writes ("Re: Bug#492698: appears to be vulnerable to cache poisoning attack CVE-2008-1447"):
> [ CC'ing Ian. ]
> Ian, are you planning a fix for this?

The short answer is no, not in any reasonable timescale.  It's not
even clear whether a fix is possible for a stub resolver, which
typically doesn't have the luxury of a whole IP address to itself and
which can't reasonably allocate thousands of ports.

adns has always used entirely predictable sequence numbers and expects
that the path between it and the nameserver does not permit an
attacker to inject spoofed packets that appear to come from the
nameserver.  Quoting the source:

  setup.c:  ads->nextid= 0x311f;

This is documented in INSTALL:

  SECURITY AND PERFORMANCE - AN IMPORTANT NOTE

  adns is not a `full-service resolver': it does no caching of responses
  at all, and has no defence against bad nameservers or fake packets
  which appear to come from your real nameservers.  It relies on the
  full-service resolvers listed in resolv.conf to handle these tasks.

  For secure and reasonable operation you MUST run a full-service
  nameserver on the same system as your adns applications, or on the
  same local, fully trusted network.  You MUST only list such
  nameservers in the adns configuration (eg resolv.conf).

  You MUST use a firewall or other means to block packets which appear
  to come from these nameservers, but which were actually sent by other,
  untrusted, entities.

  Furthermore, adns is not DNSSEC-aware in this version; it doesn't
  understand even how to ask a DNSSEC-aware nameserver to perform the
  DNSSEC cryptographic signature checking.


Ian.

-- 
Robert Edmonds
edmonds at gtisc.gatech.edu