FreeBSD 7.1 and BIND exploit

[Max Laier]

On Tuesday 22 July 2008 00:31:53 Charles Sprickman wrote:
> On Mon, 21 Jul 2008, Kevin Oberman wrote:
> >> From: Max Laier <max at love2party.net>
> >> Date: Mon, 21 Jul 2008 21:38:46 +0200
> >> Sender: owner-freebsd-stable at freebsd.org
> >>
> >> On Monday 21 July 2008 21:14:22 Doug Barton wrote:
> >>> Brett Glass wrote:
> >>> | Everyone:
> >>> |
> >>> | Will FreeBSD 7.1 be released in time to use it as an upgrade to
> >>> | close the BIND cache poisoning hole?
> >>>
> >>> Brett, et al,
> >>>
> >>> I'll make this simple for you. If you have a server that is running
> >>> BIND, update BIND now. If you need to use the ports, that's fine,
> >>> just do it now. Make sure that you are not specifying a port via
> >>> any query-source* options in named.conf, and that any firewall
> >>> between your named process and the outside world does keep-state on
> >>> outgoing UDP packets.
> >>
> >> ... and that any NAT device employs at least a somewhat random port
> >> allocation mechanism - pf provides this.
> >
> > And, if you are not sure how good a job it does (and I am not), you
> > should use the OARC test to check how well it works:
> > dig +short porttest.dns-oarc.net TXT
> >
> > If the result is not "GOOD", it's not good enough.
>
> I was playing around with this a bit.  It seems like a patched server
> will give a standard deviation of more than 18,000.  If I make some
> queries behind a one-to-many NAT using pf, it falls to somewhere around
> 6,000 (with a patched BIND - unpatched is pitiful).

While the standard deviation gives some *indication* about the randomness 
of the selection it is no real measurement for its quality.

> PF is not *adding* any randomness to unpatched servers.  Since it has a
> (non-configurable?) range of ports it will grab when doing outbound
> NAT, the results are not as good as with no NAT intervention, but
> passable I suppose.

You can configure the range on a per-NAT-rule basis, e.g.:

 nat on $ext_if inet from ! ($ext_if) to any -> ($ext_if) port 1024:65535

but you have to take care so that you don't collide with the ephemeral 
port range of the host itself.

Obviously you can't do much about an unpatched bind as with UDP there is 
no notion of "connection" so pf (or any NAT device for that matter) has 
to keep the NAT binding open for "some time" and a quick sequence of 
queries to the same server will be sent out through the same port.  So 
putting a NAT firewall in front of a DNS resolver is *NOT* a workaround!

> Of course in a 1:1 NAT setup it is transparent.
>
> Charles
>
> > You can test a remote server by adding "@remote-server" to the dig
> > command. The server may be specified by name or IP address.
> >
> > Don't forget that ANY server that caches data, including an end
> > system running a caching only server is vulnerable.
> > --
> > R. Kevin Oberman, Network Engineer
> > Energy Sciences Network (ESnet)
> > Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
> > E-mail: oberman at es.net			Phone: +1 510 486-8634
> > Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751



-- 
/"\  Best regards,                      | mlaier at freebsd.org
\ /  Max Laier                          | ICQ #67774661
 X   http://pf4freebsd.love2party.net/  | mlaier at EFnet
/ \  ASCII Ribbon Campaign              | Against HTML Mail and News