Bug 449345 - (CVE-2008-1447) CVE-2008-1447 bind: implement source UDP port randomization (CERT VU#800113)
CVE-2008-1447 bind: implement source UDP port randomization (CERT VU#800113)
Status: CLOSED ERRATA
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
low Severity low
: ---
: ---
Assigned To: Red Hat Product Security
impact=important,source=cert,reported...
: Security
Depends On: 450256 450257 450258 450259 450260 450261 454475 454476 454477 454566 454869 454870 833888
Blocks: 580448
  Show dependency treegraph
 
Reported: 2008-06-02 06:31 EDT by Mark J. Cox (Product Security)
Modified: 2015-06-12 04:28 EDT (History)
12 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-06-20 10:40:48 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
proposed patch, ready for backporting (40.62 KB, patch)
2008-06-05 12:36 EDT, Mark J. Cox (Product Security)
no flags Details | Diff

  None (edit)
Comment 4 Mark J. Cox (Product Security) 2008-06-05 12:36:22 EDT
Created attachment 308453 [details]
proposed patch, ready for backporting 

Here is their patch against 9.3.5 (they didn't supply a patch, just 9.3.5-p1
which I compared against 9.3.5 and removed all the makefile/windows build
noise)
Comment 6 Mark J. Cox (Product Security) 2008-06-06 07:39:25 EDT
fix CVE name typo, correct CVE is CVE-2008-1447.
Comment 15 Mark J. Cox (Product Security) 2008-07-03 06:11:28 EDT
The DNS protocol protects against spoofing attacks by requiring an attacker
to predict both the DNS transaction ID and UDP source port of a request.
In the last few years a number of papers have found problems with DNS
implementations making it easier for an attacker to perform DNS cache
poisoning attacks.

Previous versions of BIND did not use randomized UDP source ports which
could make DNS cache poisoning attacks easier if an attacker is able to
predict the random DNS transaction ID. In order to provide more resilience,
BIND has been updated to use a range of random UDP source ports.
(CVE-2008-1447)

Acknowledgements:

Red Hat would like to thank Dan Kaminsky for reporting this issue.
Comment 18 Mark J. Cox (Product Security) 2008-07-03 10:55:12 EDT
Note that we have provided updated SELinux policies for Red Hat Enterprise Linux
4 and 5 in the errata.  Previous policies would block BIND from using randomized
source ports and you'd see avc messages similar to:

type=SYSCALL msg=audit(1213788852.230:25): arch=40000003 syscall=102 success=no
exit=-13 a0=2 a1=b7f0ef30 a2=ae8210 a3=9220638 items=0 ppid=1 pid=2610 auid=0
uid=25 gid=25 euid=25 suid=25 fsuid=25 egid=25 sgid=25 fsgid=25 tty=(none) ses=1
comm="named" exe="/usr/sbin/named" subj=root:system_r:named_t:s0 key=(null)
type=AVC msg=audit(1213788854.232:26): avc:  denied  { name_bind } for  pid=2610
comm="named" src=62172 scontext=root:system_r:named_t:s0
tcontext=system_u:object_r:port_t:s0 tclass=udp_socket
type=SYSCALL msg=audit(1213788854.232:26): arch=40000003 syscall=102 success=no
exit=-13 a0=2 a1=b7f0ef00 a2=ae8210 a3=9224c38 items=0 ppid=1 pid=2610 auid=0
uid=25 gid=25 euid=25 suid=25 fsuid=25 egid=25 sgid=25 fsgid=25 tty=(none) ses=1
comm="named" exe="/usr/sbin/named" subj=root:system_r:named_t:s0 key=(null)
type=AVC msg=audit(1213788855.044:27): avc:  denied  { name_bind } for  pid=2610
comm="named" src=32589 scontext=root:system_r:named_t:s0
tcontext=system_u:object_r:port_t:s0 tclass=udp_socket
Comment 23 Mark J. Cox (Product Security) 2008-07-08 13:32:59 EDT
This issue is now public via MS advisory MS08-037, however the advisory text
implies that CVE-2008-1447 relates to how Microsoft DNS service contained
insufficient socket entropy in both the transaction ID and UDP sockets.  BIND
(since updates in previous years) has had sufficient transaction ID entropy.  It
is therefore likely that the CVE name will be split in the future.

http://www.microsoft.com/technet/security/Bulletin/MS08-037.mspx
Comment 24 Mark J. Cox (Product Security) 2008-07-08 13:52:19 EDT
Opening bug, now public via
http://lists.debian.org/debian-security-announce/2008/msg00184.html
Comment 25 Mark J. Cox (Product Security) 2008-07-08 14:16:05 EDT
Updates available for BIND for Red Hat Enterprise Linux 2.1, 3, 4, and 5:

    https://rhn.redhat.com/errata/RHSA-2008-0533.html

Comment 27 Mark J. Cox (Product Security) 2008-07-08 15:15:05 EDT
As an aside; the Linux kernel 2.6.24 implements random source ports for UDP
(where none is specified by the application),  However we do not ship a kernel
that implements UDP port randomization in Red Hat Enterprise Linux 2.1, 3, 4, or 5.
Comment 28 Tuomo Soini 2008-07-09 01:39:55 EDT
named.conf.sample should be modified and these lines removed. Users of sample
named.conf are still vulnerable after this update because of these.

        /* make named use port 53 for the source of all queries, to allow
         * firewalls to block all ports except 53:
         */
        query-source    port 53;        
        query-source-v6 port 53;
Comment 29 Tomas Hoger 2008-07-09 08:43:56 EDT
List of other DNS implementations, that may be affected by this issue:

  http://www.openwall.com/lists/oss-security/2008/07/09/4

Relevant ones:
- dnsmasq - affected, no upstream fix so far
  http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2008q3/002147.html

Fedora only:
- MaraDNS - should be unaffected / mostly unaffected

- PowerDNS / pdns-recursor - not affected, according to vendor statement in Cert
advisory:
  http://www.kb.cert.org/vuls/id/800113
  http://www.kb.cert.org/vuls/id/CRDY-7FFQZ6
  http://mailman.powerdns.com/pipermail/pdns-users/2008-July/005524.html

(Adding maintainers to CC, feel free to remove yourself if you are not
interested and/or DNS resolver you maintain is unaffected.)
Comment 30 Michael Fleming 2008-07-09 08:58:34 EDT
MaraDNS isn't affected according to Sam Tremholme's MaraDNS blog:

http://maradns.blogspot.com/2008/07/maradns-is-immune-to-new-cache.html
Comment 31 Fedora Update System 2008-07-09 17:45:17 EDT
bind-9.5.0-33.P1.fc9 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 32 Fedora Update System 2008-07-09 17:48:27 EDT
bind-9.5.0-28.P1.fc8 has been pushed to the Fedora 8 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 34 Tuomo Soini 2008-07-10 00:55:08 EDT
caching-nameserver  config needs fix too.

--- named.caching-nameserver.conf.orig  2008-07-10 07:49:02.000000000 +0300
+++ named.caching-nameserver.conf       2008-07-10 07:48:03.000000000 +0300
@@ -18,6 +18,8 @@
        dump-file       "/var/named/data/cache_dump.db";
         statistics-file "/var/named/data/named_stats.txt";
         memstatistics-file "/var/named/data/named_mem_stats.txt";
+       query-source    port 53;
+       query-source-v6 port 53;
        allow-query     { localhost; };
 };
 logging {
Comment 35 Tuomo Soini 2008-07-10 01:02:52 EDT
In fact my patch was reversed but idea should be clear.
Comment 36 Mark J. Cox (Product Security) 2008-07-10 09:18:23 EDT
Red Hat Enterprise Linux 5.1 shipped with new package dnsmasq used for libvirt.
 dnsmasq does use a fixed source port when talking to the upstream nameservers.
 This is not as serious an issue as with BIND caching-nameserver; with dnsmasq
the attacker would need to be on the network 'between' dnsmasq and the (fixed)
upstream nameservers.

See upstream commentary about this issue here:
http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2008q3/002147.html
http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2008q3/002148.html
http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2008q3/002165.html
(and follow-ups)
Comment 38 Daniel Veillard 2008-07-10 09:39:34 EDT
libvirt use of dnsmasq is really to provide dhcp and DNS on a virtual subnet
for virtual machines running on the same node. 
When run from libvirtd (the libvirt daemon) and based on the default config
the command used is

/usr/sbin/dnsmasq --keep-in-foreground --strict-order --bind-interfaces
--pid-file  --conf-file  --listen-address 192.168.122.1 --except-interface lo
--dhcp-leasefile=/var/lib/libvirt/dhcp-default.leases --dhcp-range
192.168.122.2,192.168.122.254

  i.e. it listens only on the localhost interface

       -z, --bind-interfaces
              On systems which support it, dnsmasq binds the wildcard address,
              even when it is listening on only some interfaces. It then  dis-
              cards  requests  that it shouldn’t reply to. This has the advan-
              tage of working even when interfaces  come  and  go  and  change
              address.  This  option  forces  dnsmasq  to really bind only the
              interfaces it is listening on. About the only time when this  is
              useful  is  when running another nameserver (or another instance
              of dnsmasq) on  the  same  machine.  Setting  this  option  also
              enables multiple instances of dnsmasq which provide DHCP service
              to run in the same machine.

  So based on the use done by libvirt, I don't think there is a risk in that
setup (but I'm not an expert).
  However since the package is generally available I will check for further
versions posted 

Daniel
Comment 39 Mark J. Cox (Product Security) 2008-07-10 15:57:27 EDT
[Updated 10th July 2008]
We have updated the Enterprise Linux 5 BIND packages. The
default and sample caching-nameserver configuration files have been updated
so that they do not specify a fixed query-source port. Administrators
wishing to take advantage of randomized UDP source ports should check their
configuration file to ensure they have not specified fixed query-source ports.

https://rhn.redhat.com/errata/RHSA-2008-0533.html
Comment 40 Fedora Update System 2008-10-08 10:21:02 EDT
ruby-1.8.6.287-2.fc8 has been submitted as an update for Fedora 8.
http://admin.fedoraproject.org/updates/ruby-1.8.6.287-2.fc8
Comment 41 Fedora Update System 2008-10-08 10:23:02 EDT
ruby-1.8.6.287-2.fc9 has been submitted as an update for Fedora 9.
http://admin.fedoraproject.org/updates/ruby-1.8.6.287-2.fc9
Comment 42 Fedora Update System 2008-10-09 17:29:26 EDT
ruby-1.8.6.287-2.fc9 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 43 Jeffrey C. Ollie 2009-11-02 15:02:35 EST
Here's another security-related bug that can be closed, AFAICS.  Is there a reason to keep it open any longer?

Note You need to log in before you can comment on or make changes to this bug.