Re: Insecure DNS servers on PG infrastructure

On Fri, Jul 25, 2008 at 11:02:03AM -0400, Tom Lane wrote:
> I just noted that cvs.postgresql.org and svr1.postgresql.org are not
> running the latest bind release, which means that they are vulnerable to
> the DNS cache poisoning attack recently discovered by Dan Kaminsky.
> Vixie and co think this is a pretty big deal, so folks might want to
> update sooner rather than later.

This is an extremely big deal. The numbers I've seen suggest windows
somewhere around 10 minutes. If the systems above are doing
recursion, then they need to be patched right away. (If they're
running both authority and recursive services in the same BIND
instance, I suggest that the practice be abandoned immediately.)

> BTW, there is an excellent end-to-end test available for whether the
> security fix (port randomization) is actually working for you:
>
> dig @server-to-test porttest.dns-oarc.net in txt
>
> This takes a few seconds (they've arranged it to force multiple queries
> from the tested server) and gives you back a readout of how many ports
> those queries arrived from and the spread in the port addresses.

Note the TTL, BTW, so that running it twice in a row gives exactly the
same answer. You need to wait for the cache to expire to repeat your tests.

> If it says FAIR or POOR then you have an unpatched server or there
> is something interfering with the port randomization. If the server
> is behind a NAT firewall then the latter is entirely likely.

There's no reason that a NAT should do that, if the device is
competently built: if you randomise source ports on the inside, the
NAT device could just use the same port on the outside.

Much worse is the bad habit many got into recently of nailing the
source port to 53, and then only opening that on the firewall on the
way out. Some packages have had this behaviour turned on by default.
Setting the source port this way will foil the patch that is included
in BIND. You need to make your recursive queries from a random port,
and the port needs to be unpredictable by someone watching your
resolver.

If you want to try another recursive-only resolver (one that is much
more recent and so was never vulnerable to this attack), have a look
at unbound (find it at unbound.net). It can do DNSSEC validation for
you too.

BTW, the strategies that BIND and others are using to foil the
Kaminsky attack merely reduce the liklihood, and don't prevent it
completely. There's not a lot of source ports over which to
randomize. The real solution to all this is DNSSEC, but deploying it
isn't trivial, and the root isn't signed yet. (.ORG will be soon,
though!)

A

--
Andrew Sullivan
ajs(at)commandprompt(dot)com
+1 503 667 4564 x104
http://www.commandprompt.com/