[Fwd: cvs commit: ports/dns/bind9 Makefile distinfo ports/dns/bind94 Makefile distinfo ports/dns/bind95 Makefile distinfo]

[Remko Lodder]

Dear all,

Doug just updated the ports tree with the updated BIND ports. If you
urgently want to upgrade and really cannot wait for the advisory. Please
use the ports system to get up to speed.

Thanks Doug for working on this on such short notice!

Cheers,
remko

-------- Original Message --------
Subject: cvs commit: ports/dns/bind9 Makefile distinfo ports/dns/bind94
Makefile distinfo ports/dns/bind95 Makefile distinfo
Date: Wed, 9 Jul 2008 19:02:01 +0000 (UTC)
From: Doug Barton <dougb@...>
To: ports-committers@..., cvs-ports@..., cvs-all@...

dougb       2008-07-09 19:02:01 UTC

   FreeBSD ports repository

   Modified files:
     dns/bind9            Makefile distinfo
     dns/bind94           Makefile distinfo
     dns/bind95           Makefile distinfo
   Log:
   Upgrade to the -P1 versions of each port, which add stronger
randomization
   of the UDP query-source ports. The server will still use the same query
   port for the life of the process, so users for whom the issue of cache
   poisoning is highly significant may wish to periodically restart their
   server using /etc/rc.d/named restart, or other suitable method.

   In order to take advantage of this randomization users MUST have an
   appropriate firewall configuration to allow UDP queries to be sent and
   answers to be received on random ports; and users MUST NOT specify a
   port number using the query-source[-v6] option.

   The avoid-v[46]-udp-ports options exist for users who wish to eliminate
   certain port numbers from being chosen by named for this purpose. See
   the ARM Chatper 6 for more information.

   Also please note, this issue applies only to UDP query ports. A random
   ephemeral port is always chosen for TCP queries.

   This issue applies primarily to name servers whose main purpose is to
   resolve random queries (sometimes referred to as "caching" servers, or
   more properly as "resolving" servers), although even an "authoritative"
   name server will make some queries, primarily at startup time.

   This update addresses issues raised in:
   http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1447
   http://www.kb.cert.org/vuls/id/800113
   http://tools.ietf.org/html/draft-ietf-dnsext-forgery-resilience

   Revision  Changes    Path
   1.82      +2 -2      ports/dns/bind9/Makefile
   1.44      +6 -6      ports/dns/bind9/distinfo
   1.85      +2 -3      ports/dns/bind94/Makefile
   1.47      +6 -6      ports/dns/bind94/distinfo
   1.87      +2 -2      ports/dns/bind95/Makefile
   1.49      +6 -6      ports/dns/bind95/distinfo
_______________________________________________
cvs-ports@... mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-ports
To unsubscribe, send any mail to "cvs-ports-unsubscribe@..."

--

/"\   Best regards,                      | remko@...
\ /   Remko Lodder                       | remko@EFnet
  X    http://www.evilcoder.org/          |
/ \   ASCII Ribbon Campaign              | Against HTML Mail and News
_______________________________________________
freebsd-security@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@..."

[Andrew Storms]

Nice. Thanks Doug!


On 7/9/08 12:05 PM, "Remko Lodder" <remko@...> wrote:

> Dear all,
>
> Doug just updated the ports tree with the updated BIND ports. If you
> urgently want to upgrade and really cannot wait for the advisory. Please
> use the ports system to get up to speed.
>
> Thanks Doug for working on this on such short notice!
>
> Cheers,
> remko

_______________________________________________
freebsd-security@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@..."

[Stef Walter]

Thanks!

Here are simple steps to use this instead of the base named (and easily
go back later):

# cd /usr/ports/dns/bind9
# make && make install
# ln -s /etc/namedb/named.conf /usr/local/etc/named.conf
# echo 'named_program="/usr/local/sbin/named" >> /etc/rc.conf
# /etc/rc.d/named restart

LMK if I missed something.

Cheers,
Stef

Andrew Storms wrote:

> Nice. Thanks Doug!
>
>
> On 7/9/08 12:05 PM, "Remko Lodder" <remko@...> wrote:
>
>> Dear all,
>>
>> Doug just updated the ports tree with the updated BIND ports. If you
>> urgently want to upgrade and really cannot wait for the advisory. Please
>> use the ports system to get up to speed.
>>
>> Thanks Doug for working on this on such short notice!
>>
>> Cheers,
>> remko
>
> _______________________________________________
> freebsd-security@... mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-security
> To unsubscribe, send any mail to "freebsd-security-unsubscribe@..."
>

_______________________________________________
freebsd-security@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@..."

[Dmitry Morozovsky]

On Wed, 9 Jul 2008, Stef wrote:

S> Thanks!
S>
S> Here are simple steps to use this instead of the base named (and easily
S> go back later):
S>
S> # cd /usr/ports/dns/bind9
S> # make && make install
S> # ln -s /etc/namedb/named.conf /usr/local/etc/named.conf
S> # echo 'named_program="/usr/local/sbin/named" >> /etc/rc.conf
S> # /etc/rc.d/named restart
S>
S> LMK if I missed something.

(or use NO_BIND= in /etc/make.conf and WITH_REPLACE_BASE= on port options, but
be careful when upgrading configs...)

Just to have you and other related parties informed of a pitfall I stepped
into:

-- 8< --
From: BIND9 Bugs via RT <bind9-bugs@...>
Subject: [ISC-Bugs #18265] AutoReply: bind update to 9.4.2.1: 'empty label' inconsistent check

-------------------------------------------------------------------------
Dear Doug and ISC maintainers,

just updated bind94 on our master server and found that together with
vulnerability fixes there is at least one glitch in configuration checks

History: we have automatic scripted system to secondary some zones from one of
our partners. so, part of named.conf is auto-generated, then checked via
named-checkconf and then applied.

After today upgrade I found that new server failed to start, which is really a
PITA, as it has 13k+ authoritative zones. Named-checkconf does not return an
error. named reports 'empty label' without any reference to config file and/or
line number. After some nervous minutes of binary search ;-) I found the
offending line, which erroneously contains two dots instead of one.

I suppose this should be fixed at least in named-checkconf.

-- 8< --



Sincerely,
D.Marck                                     [DM5020, MCK-RIPE, DM3-RIPN]
[ FreeBSD committer:                                 marck@... ]
------------------------------------------------------------------------
*** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@... ***
------------------------------------------------------------------------
_______________________________________________
freebsd-security@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@..."

[Doug Barton]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

First off, to those who were kind enough to offer thanks, "you're
welcome." :)

Second, one user wrote me privately to indicate that my statement in
the first paragraph of my commit message was not clear. The point to
this change is that for _each_ outgoing query a _new, random_ UDP
source port is used, _as well as_ the standard query ID. (This is of
course assuming that you do not have a port locked down in named.conf,
which no one should at this point unless firewall rules outside of
your control mandate it.) However, named is still picking a "random"
UDP port on startup and locking it down (2 if you're also using IPv6)
although it's not immediately clear to me why (I do have a query as to
the reason in progress).

Stef wrote:
| Thanks!
|
| Here are simple steps to use this instead of the base named (and easily
| go back later):
|
| # cd /usr/ports/dns/bind9

Actually I'd at least use bind94, and preferably bind95. Either of
those two will have better memory management characteristics than the
9.3.x that is in dns/bind9.

| # make && make install
| # ln -s /etc/namedb/named.conf /usr/local/etc/named.conf

You will also need to do the same with the rndc.key file, and if you
are running in the chroot (the default for the rc.d script) then you
will need to create /var/named/usr/local/etc and repeat the exercise
for both files.

| # echo 'named_program="/usr/local/sbin/named" >> /etc/rc.conf

Personally my preference would be to edit the rc.conf[.local] file.

| # /etc/rc.d/named restart

I would actually do 'rndc stop' first, then '/etc/rc.d/named start'
but for most purposes the differences there would be minor.

You can also use the "replace base bind" option in the 'make config'
step which would obviate editing named_program above. If you do that,
add 'WITHOUT_BIND=   yes' in /etc/src.conf for 7 or 8, and 'NO_BIND=
yes' in /etc/make.conf in 6.


hope this helps,

Doug

- --

~    This .signature sanitized for your protection

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (FreeBSD)

iEYEAREDAAYFAkh2o/4ACgkQyIakK9Wy8PurfQCfeN7Vvme3PABgFWMPhQz1Kgu6
gVUAni9iCNt0Gzi2YntV6uQmmRI8MhQl
=4Blu
-----END PGP SIGNATURE-----
_______________________________________________
freebsd-security@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@..."

[Doug Barton]

Doug Barton wrote:
> However, named is still picking a "random" UDP port on startup and
> locking it down (2 if you're also using IPv6) although it's not
> immediately clear to me why.

And the answer is .... in order to make the -P1 releases as clean as
possible, that part of the code was not touched (which I think is a very
good decision) and that port may continue to see use down the road.

hope this helps,

Doug

--

     This .signature sanitized for your protection
_______________________________________________
freebsd-security@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@..."

[Artis Caune-3]

On Wed, Jul 9, 2008 at 10:05 PM, Remko Lodder <remko@...> wrote:
> Dear all,
>
> Doug just updated the ports tree with the updated BIND ports. If you
> urgently want to upgrade and really cannot wait for the advisory. Please use
> the ports system to get up to speed.

Has anyone tried to run bind95?

I updated bind94-9.4.2_1 to bind95-9.5.0.1 and after couple of hours
it eated all 2G of ram and 1G of swap and was killed.
max-cache-size was set to 1500M, same problem with 64M. Looks like
bind95 is leaking memory.
FreeBSD-7.0/amd64, 2K queries/sec

bind94-4.2.1 works just fine.

thanks,
Artis
_______________________________________________
freebsd-security@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@..."

[Brett Glass]

Is there a way to restrict the ports which BIND selects -- perhaps
at the expense of a small amount of entropy -- such that it doesn't
try to use UDP ports which are administratively blocked (e.g. ports
used by worms, or insecure Microsoft network utilities)? We don't
dare turn these port blocks off, or naive users will fall prey to
security holes in Microsoft products. But if BIND doesn't know to
work around them, lookups will occasionally (and infuriatingly!)
fail.

--Brett Glass

At 06:06 PM 7/10/2008, Doug Barton wrote:
 

>First off, to those who were kind enough to offer thanks, "you're
>welcome." :)
>
>Second, one user wrote me privately to indicate that my statement in
>the first paragraph of my commit message was not clear. The point to
>this change is that for _each_ outgoing query a _new, random_ UDP
>source port is used, _as well as_ the standard query ID. (This is of
>course assuming that you do not have a port locked down in named.conf,
>which no one should at this point unless firewall rules outside of
>your control mandate it.) However, named is still picking a "random"
>UDP port on startup and locking it down (2 if you're also using IPv6)
>although it's not immediately clear to me why (I do have a query as to
>the reason in progress).

_______________________________________________
freebsd-security@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@..."

[Jeremy Chadwick-3]

On Fri, Jul 11, 2008 at 08:54:48AM -0600, Brett Glass wrote:
> Is there a way to restrict the ports which BIND selects -- perhaps
> at the expense of a small amount of entropy -- such that it doesn't
> try to use UDP ports which are administratively blocked (e.g. ports
> used by worms, or insecure Microsoft network utilities)? We don't
> dare turn these port blocks off, or naive users will fall prey to
> security holes in Microsoft products. But if BIND doesn't know to
> work around them, lookups will occasionally (and infuriatingly!)
> fail.

query-source has an argument called "port" which will do what you want.
That option *only* affects UDP queries, however; TCP queries are always
random.

--
| Jeremy Chadwick                                jdc at parodius.com |
| Parodius Networking                       http://www.parodius.com/ |
| UNIX Systems Administrator                  Mountain View, CA, USA |
| Making life hard for others since 1977.              PGP: 4BD6C0CB |

_______________________________________________
freebsd-security@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@..."

[Alan Clegg]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jeremy Chadwick wrote:

> On Fri, Jul 11, 2008 at 08:54:48AM -0600, Brett Glass wrote:
>> Is there a way to restrict the ports which BIND selects -- perhaps
>> at the expense of a small amount of entropy -- such that it doesn't
>> try to use UDP ports which are administratively blocked (e.g. ports
>> used by worms, or insecure Microsoft network utilities)? We don't
>> dare turn these port blocks off, or naive users will fall prey to
>> security holes in Microsoft products. But if BIND doesn't know to
>> work around them, lookups will occasionally (and infuriatingly!)
>> fail.
>
> query-source has an argument called "port" which will do what you want.
> That option *only* affects UDP queries, however; TCP queries are always
> random.

While query-source allows you to lock down to a single port, you DO NOT
WANT TO DO THIS -- if you do, you will be vulnerable to the very thing
that the patch made you immune (well, safer) from.

What Brett (and others) need to do is risk the waters with the new beta
code (9.4.3b2 and 9.5.1b1) which includes additional "fine-grained"
control for the UDP ports to be used.

Please, PLEASE, do not introduce "query-source port XX" into your
configurations.

AlanC
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD4DBQFId4LEcKpYUrUDCYcRAiowAJ47bCASBmTszN8A7d1MbEvB9ZJq0wCWMZIK
t8Uv4q/ro3MDpEP71GqtHg==
=+SwG
-----END PGP SIGNATURE-----
_______________________________________________
freebsd-security@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@..."

[Matthew Seaman-2]

Alan Clegg wrote:
> Jeremy Chadwick wrote:
>> On Fri, Jul 11, 2008 at 08:54:48AM -0600, Brett Glass wrote:

>>> Is there a way to restrict the ports which BIND selects -- perhaps
>>> at the expense of a small amount of entropy -- such that it doesn't
>>> try to use UDP ports which are administratively blocked (e.g. ports
>>> used by worms, or insecure Microsoft network utilities)? We don't
>>> dare turn these port blocks off, or naive users will fall prey to
>>> security holes in Microsoft products. But if BIND doesn't know to
>>> work around them, lookups will occasionally (and infuriatingly!)
>>> fail.

>> query-source has an argument called "port" which will do what you want.
>> That option *only* affects UDP queries, however; TCP queries are always
>> random.
 

> While query-source allows you to lock down to a single port, you DO NOT
> WANT TO DO THIS -- if you do, you will be vulnerable to the very thing
> that the patch made you immune (well, safer) from.
>
> What Brett (and others) need to do is risk the waters with the new beta
> code (9.4.3b2 and 9.5.1b1) which includes additional "fine-grained"
> control for the UDP ports to be used.
>
> Please, PLEASE, do not introduce "query-source port XX" into your
> configurations.

Probably what Brett is looking for are the avoid-v4-udp-ports  and avoid-v6-udp-ports options -- these just contain lists of UDP ports
to avoid as the source of any DNS traffic.  Details are available here
(for bind95) http://www.isc.org/sw/bind/arm95/Bv9ARM.ch06.html#options
but it's the same for all 9.x versions of BIND.

        Cheers,

        Matthew

--
Dr Matthew J Seaman MA, D.Phil.                   7 Priory Courtyard
                                                  Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey     Ramsgate
                                                  Kent, CT11 9PW

[Jeremy Chadwick-3]

On Fri, Jul 11, 2008 at 11:56:53AM -0400, Alan Clegg wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Jeremy Chadwick wrote:
> > On Fri, Jul 11, 2008 at 08:54:48AM -0600, Brett Glass wrote:
> >> Is there a way to restrict the ports which BIND selects -- perhaps
> >> at the expense of a small amount of entropy -- such that it doesn't
> >> try to use UDP ports which are administratively blocked (e.g. ports
> >> used by worms, or insecure Microsoft network utilities)? We don't
> >> dare turn these port blocks off, or naive users will fall prey to
> >> security holes in Microsoft products. But if BIND doesn't know to
> >> work around them, lookups will occasionally (and infuriatingly!)
> >> fail.
> >
> > query-source has an argument called "port" which will do what you want.
> > That option *only* affects UDP queries, however; TCP queries are always
> > random.
>
> While query-source allows you to lock down to a single port, you DO NOT
> WANT TO DO THIS -- if you do, you will be vulnerable to the very thing
> that the patch made you immune (well, safer) from.
>
> What Brett (and others) need to do is risk the waters with the new beta
> code (9.4.3b2 and 9.5.1b1) which includes additional "fine-grained"
> control for the UDP ports to be used.
>
> Please, PLEASE, do not introduce "query-source port XX" into your
> configurations.

The problem here is WRT network ACLs.  The only solution is to bind BIND
to a specific IP address and permit any outbound TCP or UDP traffic +
any inbound TCP or UDP traffic to port 53.  Most network administrators
I know of won't like that, as they deny all incoming *and* outgoing
traffic, then apply permit ACLs.  There's no "clean" or "strict" permit
ACL, while with port XX, you can at least narrow down things UDP-wise a
bit more.

I'll add that the stock src/etc/namedb/named.conf even advocates the use
of query-source ... port 53.  I'm sure this will be changed as a result
of the recent security issue.

--
| Jeremy Chadwick                                jdc at parodius.com |
| Parodius Networking                       http://www.parodius.com/ |
| UNIX Systems Administrator                  Mountain View, CA, USA |
| Making life hard for others since 1977.              PGP: 4BD6C0CB |

_______________________________________________
freebsd-security@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@..."

[Doug Barton]

Jeremy Chadwick wrote:

> The problem here is WRT network ACLs.  The only solution is to bind BIND
> to a specific IP address and permit any outbound TCP or UDP traffic +
> any inbound TCP or UDP traffic to port 53.

Not quite any inbound traffic, named will pick a source port > 1024. In
the current beta versions there is an option to restrict the ports
chosen to a range.

I'm also not quite sure what kind of server you're talking about here.
If it's authoritative, then by definition you have to allow all inbound
traffic to port 53.

> Most network administrators
> I know of won't like that, as they deny all incoming *and* outgoing
> traffic, then apply permit ACLs.  There's no "clean" or "strict" permit
> ACL, while with port XX, you can at least narrow down things UDP-wise a
> bit more.

False economy. The "danger" of allowing inbound UDP traffic is
infinitely less than the danger of having a recursive resolver's cache
poisoned. The new way of things would be to define those UDP ports that
run services other than named on the system, add those to the avoid-*
option(s) in named.conf, and block those ports at the firewall, leaving
everything else open.

Of course, almost any modern firewall should have keep-state
functionality for UDP, so all of this should be moot.

> I'll add that the stock src/etc/namedb/named.conf even advocates the use
> of query-source ...

It doesn't advocate, it gives an example. This is the reason I am
resistant to adding too many examples to our installed named.conf, it is
too easy for people to misinterpret them.

Doug

--

     This .signature sanitized for your protection
_______________________________________________
freebsd-security@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@..."

[Doug Barton]

Artis Caune wrote:

> I updated bind94-9.4.2_1 to bind95-9.5.0.1 and after couple of hours
> it eated all 2G of ram and 1G of swap and was killed.

The best place to report these issues is bind-users@....

Good luck,

Doug

--

     This .signature sanitized for your protection

_______________________________________________
freebsd-security@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@..."

[Alan Clegg]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Matthew Seaman wrote:

> Probably what Brett is looking for are the avoid-v4-udp-ports  and
> avoid-v6-udp-ports options -- these just contain lists of UDP ports
> to avoid as the source of any DNS traffic.  Details are available here
> (for bind95) http://www.isc.org/sw/bind/arm95/Bv9ARM.ch06.html#options
> but it's the same for all 9.x versions of BIND.

This is fine as long as you are not defining large numbers of "don't
touch" ports.

The added functionality of 9.5.1b1:

  use-v4-udp-ports { range 1024 65535; };
  use-v6-udp-ports { range 1024 65535; };

Is what I was pointing people towards.

AlanC
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFId8TacKpYUrUDCYcRAhmHAJoCkQ3dxLfQhw1EamBJfNrLqwVZLwCfcfRg
VTWMnJEfymL8TH7AV2MQ7y4=
=mIl7
-----END PGP SIGNATURE-----
_______________________________________________
freebsd-security@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@..."

[Mark Andrews]

> Is there a way to restrict the ports which BIND selects -- perhaps
> at the expense of a small amount of entropy -- such that it doesn't
> try to use UDP ports which are administratively blocked (e.g. ports
> used by worms, or insecure Microsoft network utilities)? We don't
> dare turn these port blocks off, or naive users will fall prey to
> security holes in Microsoft products. But if BIND doesn't know to
> work around them, lookups will occasionally (and infuriatingly!)
> fail.

% grep avoid doc/misc/options
        avoid-v4-udp-ports { <port>; ... };
        avoid-v6-udp-ports { <port>; ... };
%

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]                 INTERNET: Mark_Andrews@...
_______________________________________________
freebsd-security@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@..."