public inbox for [email protected]  

help / color / mirror / Atom feed

From: Andrew Sullivan <[email protected]>
To: [email protected]
Subject: Re: Insecure DNS servers on PG infrastructure
Date: Fri, 25 Jul 2008 11:40:49 -0400
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>

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
[email protected]
+1 503 667 4564 x104
http://www.commandprompt.com/

view thread (11+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected]
  Subject: Re: Insecure DNS servers on PG infrastructure
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox