Dan Kaminsky Discovers Fundamental Issue In DNS: Massive Multivendor Patch Released (Securosis.com)

It doesn't say anything about djbdns either, except to link to some of his papers written
years back. Some commenter said it wasn't vuln due to port randomization.

The GNU libc stub resolver is the resolver in libc which 
reads /etc/resolv.conf and satisfies requests from almost all actual 
programs for names (the commonest class of programs that don't use the 
libc resolver are those that need asynchronous name resolution). It's 
derived from BIND8 code (IIRC, it may even be late BIND4).

This pretty much means that all Linux systems are vulnerable to cache 
pollution unless they are going via a non-vulnerable caching nameserver 
under control of someone trusted. However, since it's only a stub resolver 
and doesn't do recursive lookups, everyone has to use some caching 
nameserver anyway, simply for performance reasons... so this isn't so 
significant a problem. (adns, fairly widely used as a stub resolver when 
asynchronous name resolution is required, has the same flaw, if flaw it 
is.)

Security updates for embedded systems are poorly managed at present - doesn't matter too much
if it's a DVD player, but now that many embedded devices are Internet connected, it's a real
issue.  One example is dnsmasq, which I already have running on my DD-WRT wireless router, but
have now disabled.  

Niche distros have this problem a lot - much as I like Damn Small Linux and similar distros,
they don't seem to have any security update policy, and it's hard to know which
vulnerabilities exist.  They often run very old software and aren't usually a close derivative
of a mainstream distro, so it's almost certain they have many open vulnerabilities.

Another example is the eee PC - this runs Xandros, which you would think is easy to update
being Debian based, but in practice it seems security updates are missing or very late. One
example is a Samba vulnerability from 2007 that was not patched as of Feb 2008:
http://forum.eeeuser.com/viewtopic.php?id=14237

The general point is: how do you make consumers aware of the need for rock solid security
updates for embedded devices, and thereby cause the vendors to actually bother to implement
this properly?  Perhaps a mass of compromised devices due to this DNS cache poisoning issue is
the only way this will happen... Apparently Dan Kaminsky's attack is far more 'point and
click' than previous ones, so in a month or two we can look forward to this being incorporated
in widespread malware and used by botnets.

Maybe this lack of attention to security is simply a sign of an immature market sector - over
time perhaps the standard Linux distros will be ported / adopted, ensuring timely and complete
security updates, but in the mean time Linux on embedded devices may get a bad reputation for
security.

Sounds to me like the attack was just theoretical before, but is now 
practical.

BIND uses it's own port selection algorithm. Anyone concerned about portability and security
would too (or would check for port randomness in the configure script).

I have been castigated in the past for calling bugs bugs. Apparently 
customers think our code is bug-free as long as we don't call the, er, 
`issues' they report `bugs', even if they called them exactly that.

(sheesh, ridiculous magical thinking: or, rather, typical bleaching: 
expect `issue' to go this way in ten years or so).

If we're talking about a problem that exists in the design of DNS or
in a particular implementation, we should call it a "defect" (this is
the standard term among the safety engineers for what we programmers
informally call a "bug").  If we're talking about a problem that
exists at run-time, when something goes wrong internally, we should
call it a "fault".  If we're talking about somebody getting ripped off
because they relied on DNS and a criminal exploited DNS, then we
should call it a "failure".

It is useful to make these distinctions among different kinds of
problems, and using the word "defect" instead of "bug" makes it easier
to communicate accurately with safety engineers from other
disciplines.  (Also, as Eric Hughes suggested to me many years ago,
there may be a psychological benefit of this terminology -- a "bug"
sounds like something endogeneous, but a "defect" is clearly the
responsibility of the engineer who designed the system.)


defect -- A flaw in a system or system component that has the potential to cause that system
or component to fail to perform its required function during execution, [Jones - IBM].  	(
Reference : SEI:SE-CMM)

fault -- an incorrect step, process or data definition in a computer program  	( Reference :
ISO/IEC JTC1/SC7:14598-1)

failure -- The inability of a system or component to perform its required functions within
specified performance requirements. [IEEE STD 610.12-1990]  	( Reference : SEI:SE-CMM)

references:

http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=...

http://www.totalmetrics.com/cms/servlet/main?Subject=List...

http://en.wikipedia.org/wiki/Safety_engineering

IEEE 610.12-1990, "IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer
Glossaries"

Dan Kaminsky didn't discover the basic problem with the design of DNS or implementations of
it. This was known about years ago, to the extent DJB was aware of it and worked around it to
make DJBDNS not vulnerable to the same extent other unpatched DNS implementations are.
Kaminsky appears to have discovered an attack which exploits the problem in a more devastating
manner than previously known possible.

The basic defect in DNS isn't solved by the current set of patches. DNS without DNSSEC, even
if further third party cache-poisoning exploits are not discovered, still depends upon trust
in a chain of middlemen DNS caching servers in order to communicate authoritative DNS
information from DNS content servers to clients. So the wider issue of insecurity inherent
within the design of DNS itself remains. The additional entropy provided by these patches
makes a class of technical attacks by outsiders more difficult, but this simply delays the
inevitable need to transition to DNSSEC at some point in the future.