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.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
