[conspire] DNS vulnerability details

[Rick Moen]

While I'm still on this kick:

> o  Your Debian and MacOS boxes -- being TCP/IP-capable -- have DNS 
>    resolver libraries (DNS clients).  Neither of those OSes' libraries
>    is particularly competent at randomising their UDP ports on outgoing 
>    DNS queries whose recursive bits are set, _but_ results received 
>    back are not cached.  So, there's very little payoff to a theoretical
>    attacker from sending them forged responses with cache-poisoning data 
>    -- there being no cache to poison.  Get it?
> 
>    If there were a patch to fix those two OSes' resolver libraries,
>    that would be A Good Thing.  The one in Linux glibc is a bit of 
>    dismal code taken from <shudder> BIND8, for which, for now, there is
>    no replacement.  And there's been not a peep out of Apple about
>    prospects for fixing their resolver library.[1]

It's important to realise:  The IT press, by and large, don't understand
anything about this issue, either -- beyond there being a security
problem, and software patches.  Remember, an IT reporter tends to be
some guy or gal who, back when they were doling out asignments, showed
ability to type and knew where the "Enter" key was.  (There are
honourable exceptions, and also even the really clued ones are under
constant deadline pressure and perforce rely on what they hear from
elsewhere.)

The story about client libraries -- called "stub" resolvers because they
have just smart enough resolver code to articulate the query and offload
them to one or more _real_ recursive resolver, listed in
/etc/resolv.conf -- is a case in point.  The IT press don't get it.

I've commented online about Apple incrementing the versions of BIND9
shipped with OS X 5.4.x and 5.3.x, as part of their July 30 service
pack (Software Update 2008-05).  That was in response to a
_Computerworld_ story saying security experts were ragging on Apple for
slowness -- for which complaint there was some minor justification.
(BIND9 is included with OS X, but not enabled by default, and in fact
requires some serious neepery to enable.)
http://www.computerworld.com/comments/node/9110907?page=1

However, such news stories, and public comments on them, have been
also complaining about OS X's, Linux/glibc's, and other OSes' DNS resolver
clients being vulnerable, as if _that_ were a significant problem.  But
it isn't -- for lack of a DNS cache to poison.

_The Register_ is always among the news outlets useful for alarmism
without obvious clue:   "Apple DNS patch doesn't patch Mac clients"
(http://www.theregister.co.uk/2008/08/01/osx_still_vulnerable/)

    Both researchers found that OS X clients fail to adequately randomize
    DNS source ports, allowing attackers to poison the caches of DNS servers
    that run on the operating system.

That's a horribly garbled recounting of the facts, and misleading.  By
contrast, what the security researcher alluded to, Andrew Storms of
nSync and Swa Frantzen of Section 66, actually said was perfectly
accurate and is reasonable perspective:  They merely pointed out that
the OS X "Leopard" 10.5.4 / "Tiger" 10.4.11 resolver uses predictable
source ports on queries, and comment it should be fixed at some point.  

FreeBSD's libc has gotten fixed probably somewhere in the recent past,
and I hear that the Linux 2.6.26 kernel includes code that randomises
UDP source ports despite the underlying weakness in glibc's resolver
library code (the mess borrowed from BIND8) that gets called.  (I'm a
little unclear on the particulars.)

So, basically, improved port randomisation in client resolvers is
getting rolled out with newer OS kernels.

Having access to _reliably_ random data is actually a quite difficult
problem, and unfortunately many programmers get bitten by the results of
trying to punt the problem, e.g., by just tapping into the OS's
/dev/random or /dev/urandom.  The former tends to be pretty good (but
not great) on most 'Nixes including Linux -- _but_ tend to exhaust the
system's "entropy pool" quickly.  The latter (urandom) is an _unlocked_
random generator that re-uses the internal pool, so it produces more
numbers before conking out, but of lower quality.

A cautious programmer would look at that situation, and think "Gosh, if
my code needs reliable random data, I guess I need a decent random
number generator library (RNG), rather than just punting to the OS."  
Which is indeed what smart nameserver authors did, a long time ago.
Compare:

Caching recursive resolvers:
o  BIND9:  Wasn't smart, recently patched to compensate
o  MaraDNS:  Author built in a custom RNG from the beginning
o  PowerDNS Recursor:  Retrofitted a custom RNG in March 2008, after 
     someone filed a security bug anticipating the Kaminsky issue
o  djbdns/dnscache:  built in a custom RNG from the beginning, _and_
     the author made a point of warning everyone else of the pitfall
o  Unbound:  Author built in a custom RNG from the beginning

Caching forwarders:
o  pdnsd:  Author built in a custom RNG from the beginning
o  dnsmasq:  Wasn't smart, recently patched to compensate