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)
fix CVE name typo, correct CVE is CVE-2008-1447.
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.
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
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
Opening bug, now public via http://lists.debian.org/debian-security-announce/2008/msg00184.html
Updates available for BIND for Red Hat Enterprise Linux 2.1, 3, 4, and 5: https://rhn.redhat.com/errata/RHSA-2008-0533.html
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.
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;
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.)
MaraDNS isn't affected according to Sam Tremholme's MaraDNS blog: http://maradns.blogspot.com/2008/07/maradns-is-immune-to-new-cache.html
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.
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.
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 {
In fact my patch was reversed but idea should be clear.
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)
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
[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
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
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
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.
Here's another security-related bug that can be closed, AFAICS. Is there a reason to keep it open any longer?