Launchpad has imported 42 comments from the remote bug at https://bugzilla.redhat.com/show_bug.cgi?id=514292.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2009-07-28T17:54:14+00:00 vdanen wrote: A Debian bug report [1] notes that named can be caused to exit with an assertion failure due to a particular update packet. This will cause a complete exit of named, preventing it from serving any more DNS responses. The bug includes a reproducer in perl that can be used to trigger this. I have tried the reproducer against my local network LAN server (running CentOS 5.3) and it works as advertised, however there are a few factors that increase the complexity and reduce the exploitability of this issue. Because these are update packets, named must be setup to allow updating of records (which is typical in the case of dynamic DNS), however the RNDC key is required in order to perform the update; possibly if named is configured insecurely to allow hosts on the local network to update without the RNDC key this could be a much larger problem (unverified if that is the case). By default, both /etc/rndc.conf and /etc/rndc.key are mode 0640 and owned root:named so on the DNS server itself, someone would require named or root privileges to obtain the key; on external systems that may contain the RNDC key for updating, this would depend on that host's security. It is also required to know a FQDN that already exists on the DNS server; attempting to update a FQDN that does not exist does not cause named to exit. Sample log output for a succesful crash: Jul 28 11:30:58 hades named[18990]: db.c:579: REQUIRE(type != ((dns_rdatatype_t)dns_rdatatype_any)) failed Jul 28 11:30:58 hades named[18990]: exiting (due to assertion failure) And when the FQDN is not correct: Jul 28 11:24:36 hades named[8301]: client 10.10.10.10#36034: updating zone 'me.ca/IN': update unsuccessful: 1.me.ca/ANY: 'RRset exists (value dependent)' prerequisite not satisfied (NXRRSET) And finally, when an incorrect RNDC key is provided: Jul 28 11:30:16 hades named[18891]: client 10.10.10.10#35404: request has invalid signature: TSIG rndckey: tsig verify failure (BADSIG) Interestingly, the reproducer is a clever one as it does not exist when named crashes, so if named is restarted or is running under a supervision service to auto-restart, just leaving the reproducer running will continue to cause it to crash indefinitely unless the attacking IP is firewalled off. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=538975 Reply at: https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/406122/comments/0 ------------------------------------------------------------------------ On 2009-07-28T20:11:56+00:00 vdanen wrote: CERT has their vulnerability note here: http://www.kb.cert.org/vuls/id/725188 Reply at: https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/406122/comments/1 ------------------------------------------------------------------------ On 2009-07-28T20:13:19+00:00 vdanen wrote: Created attachment 355461 difference between 9.4.3-P2 and 9.4.3-P3 to correct this issue Upstream releases are also available: http://oldwww.isc.org/sw/bind/view?release=9.4.3-P3&noframes=1 http://oldwww.isc.org/sw/bind/view?release=9.5.1-P3&noframes=1 http://oldwww.isc.org/sw/bind/view?release=9.6.1-P1&noframes=1 Reply at: https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/406122/comments/2 ------------------------------------------------------------------------ On 2009-07-28T21:06:09+00:00 vdanen wrote: ISC's advisory on this issue: https://www.isc.org/node/474 : Description: Urgent: this exploit is public. Please upgrade immediately. Receipt of a specially-crafted dynamic update message may cause BIND 9 servers to exit. This vulnerability affects all servers – it is not limited to those that are configured to allow dynamic updates. Access controls will not provide an effective workaround. dns_db_findrdataset() fails when the prerequisite section of the dynamic update message contains a record of type “ANY” and where at least one RRset for this FQDN exists on the server. db.c:659: REQUIRE(type != ((dns_rdatatype_t)dns_rdatatype_any)) failed exiting (due to assertion failure). Workarounds: None. (Some sites may have firewalls that can be configured with packet filtering techniques to prevent nsupdate messages from reaching their nameservers.) Active exploits: An active remote exploit is in wide circulation at this time. Reply at: https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/406122/comments/3 ------------------------------------------------------------------------ On 2009-07-29T02:46:07+00:00 mhw wrote: Based on the original advisory, this appears to affect only "master" servers. One standard best practice is to have one master and multiple slaves and to protect that master (no exposure to the Internet). This would seem to be a mitigation. This is a BCP (Best Common Practice) for those of us who have been doing this for years. Sites with authoritative name servers definitely should upgrade AND fix their configurations to protect their masteres. Reply at: https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/406122/comments/4 ------------------------------------------------------------------------ On 2009-07-29T13:28:20+00:00 durval.menezes wrote: I've reproduced this bug with the stock RHEL4 bind (bind-9.2.4-30.el4_7.2). I've adapted ISC's patch for this issue to bind-9.2.4, and produced both a source package and binary packages that fix it (under the same conditions, the patched named no longer aborts), and placed it all (patch, spec file, source RPM, and binary RPMs) here: http://www.durval.com.br/RPMS/el4/bind The direct URL for the patch is http://www.durval.com.br/RPMS/el4/bind/bind-9.2.4-CVE-2009-0696.patch; please feel free to use it as appropriate. Best Regards, -- Durval Menezes <durval AT tmp DOT com DOT br> Reply at: https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/406122/comments/7 ------------------------------------------------------------------------ On 2009-07-29T13:42:39+00:00 updates wrote: bind-9.6.1-4.P1.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/bind-9.6.1-4.P1.fc11 Reply at: https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/406122/comments/8 ------------------------------------------------------------------------ On 2009-07-29T13:42:48+00:00 updates wrote: bind-9.5.1-3.P3.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/bind-9.5.1-3.P3.fc10 Reply at: https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/406122/comments/9 ------------------------------------------------------------------------ On 2009-07-29T14:09:23+00:00 yersinia.spiros wrote: (In reply to comment #11) > I've reproduced this bug with the stock RHEL4 bind (bind-9.2.4-30.el4_7.2). > > I've adapted ISC's patch for this issue to bind-9.2.4, and produced both a > source > package and binary packages that fix it (under the same conditions, the > patched > named no longer aborts), and placed it all (patch, spec file, source RPM, and > binary RPMs) here: http://www.durval.com.br/RPMS/el4/bind > > The direct URL for the patch is > http://www.durval.com.br/RPMS/el4/bind/bind-9.2.4-CVE-2009-0696.patch; > please feel free to use it as appropriate. > > Best Regards, > -- > Durval Menezes <durval AT tmp DOT com DOT br> Solaris Designer reproduce the bug also without using dynamic update quote On Wed, Jul 29, 2009 at 05:15:09PM +0400, Solar Designer wrote: > Confirmed on 9.3.5-P2 (removing the "$packet->sign_tsig(...)" line from > the exploit as above) with whatever patches we happened to have until > this latest fix. It gets worse: I was also able to crash named from an IP address explicitly denied in "allow-query". I did verify that non-malicious queries from that IP address were indeed correctly denied. It appears that BIND does too much processing too early in the code. Alexander quote Found on oss-security mailing list Reply at: https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/406122/comments/10 ------------------------------------------------------------------------ On 2009-07-29T14:11:28+00:00 thoger wrote: (In reply to comment #11) > The direct URL for the patch is > http://www.durval.com.br/RPMS/el4/bind/bind-9.2.4-CVE-2009-0696.patch; > please feel free to use it as appropriate. Updates with similar patch are undergoing quality assurance testing now and will be released as soon as they are fully tested. Reply at: https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/406122/comments/11 ------------------------------------------------------------------------ On 2009-07-29T14:35:19+00:00 rhbugzilla wrote: (In reply to comment #14) > Solaris Designer reproduce the bug also without using dynamic update ISC have already acknowledged that the bug affects instances where the configuration does not permit updates. It is not updates themselves that cause the problem, but packets masquerading as updates - whether they would work or not. Reply at: https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/406122/comments/12 ------------------------------------------------------------------------ On 2009-07-29T14:48:00+00:00 pveiga wrote: There is some workarrond for this? Regards. Priscila Veiga Reply at: https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/406122/comments/13 ------------------------------------------------------------------------ On 2009-07-29T14:48:26+00:00 pveiga wrote: https://www.isc.org/node/474 Reply at: https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/406122/comments/14 ------------------------------------------------------------------------ On 2009-07-29T15:01:14+00:00 vdanen wrote: Upon further investigation it was found that that crash is not limited to configurations that allow updates, contrary to what was originally reported. As well, the allow-query keyword does not prove an effective ACL mechanism to protect the server, as IPs that are explicitly denied by allow-query can still trigger a crash. Reply at: https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/406122/comments/15 ------------------------------------------------------------------------ On 2009-07-29T15:04:49+00:00 vdanen wrote: (In reply to comment #18) > There is some workarrond for this? The only work-around for this issue seems to be firewall-based rules to prevent unauthorized systems from talking at all to the named service. Also see comment #8 regarding master and slave servers. Reply at: https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/406122/comments/16 ------------------------------------------------------------------------ On 2009-07-29T15:29:53+00:00 atkac wrote: *** Bug 514481 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/406122/comments/17 ------------------------------------------------------------------------ On 2009-07-29T15:38:33+00:00 atkac wrote: Source RPMs of fixed packages which are undergoing quality assurance testing are also available on http://people.redhat.com/atkac/bind/. Note those packages are _NOT_ official release. Reply at: https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/406122/comments/18 ------------------------------------------------------------------------ On 2009-07-29T15:58:52+00:00 grand wrote: (In reply to comment #11) > > I've adapted ISC's patch for this issue to bind-9.2.4, and produced both a > source > package and binary packages that fix it (under the same conditions, the > patched > named no longer aborts), and placed it all (patch, spec file, source RPM, and > binary RPMs) here: http://www.durval.com.br/RPMS/el4/bind > > The direct URL for the patch is > http://www.durval.com.br/RPMS/el4/bind/bind-9.2.4-CVE-2009-0696.patch; > please feel free to use it as appropriate. > > Best Regards, > -- > Durval Menezes <durval AT tmp DOT com DOT br> You seem to be missing bind-chroot at that location. Reply at: https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/406122/comments/19 ------------------------------------------------------------------------ On 2009-07-29T16:14:41+00:00 grand wrote: Is there a possibility to back-port it to redhat 7.3? Reply at: https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/406122/comments/20 ------------------------------------------------------------------------ On 2009-07-29T16:21:48+00:00 durval.menezes wrote: (In reply to comment #28) > (In reply to comment #11) > > > > I've adapted ISC's patch for this issue to bind-9.2.4, and produced both a > > source > > package and binary packages that fix it (under the same conditions, the > > patched > > named no longer aborts), and placed it all (patch, spec file, source RPM, > > and > > binary RPMs) here: http://www.durval.com.br/RPMS/el4/bind > > > > The direct URL for the patch is > > http://www.durval.com.br/RPMS/el4/bind/bind-9.2.4-CVE-2009-0696.patch; > > please feel free to use it as appropriate. > > > > Best Regards, > > -- > > Durval Menezes <durval AT tmp DOT com DOT br> > > You seem to be missing bind-chroot at that location. Indeed. bind-chroot had strange issues at my installation, and since it's just a chroot-tree (which most/all people running bind in a chrooted configuration will already have), I just removed it initially. Will check it later and post it too. Anyway, if you need the bind-chroot, feel free to recompile it from my src.rpm. Reply at: https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/406122/comments/21 ------------------------------------------------------------------------ On 2009-07-29T16:29:46+00:00 grand wrote: (In reply to comment #33) > (In reply to comment #28) > > (In reply to comment #11) > > > > > > I've adapted ISC's patch for this issue to bind-9.2.4, and produced both a > > > source > > > package and binary packages that fix it (under the same conditions, the > > > patched > > > named no longer aborts), and placed it all (patch, spec file, source RPM, > > > and > > > binary RPMs) here: http://www.durval.com.br/RPMS/el4/bind > > > > > > The direct URL for the patch is > > > http://www.durval.com.br/RPMS/el4/bind/bind-9.2.4-CVE-2009-0696.patch; > > > please feel free to use it as appropriate. > > > > > > Best Regards, > > > -- > > > Durval Menezes <durval AT tmp DOT com DOT br> > > > > You seem to be missing bind-chroot at that location. > > Indeed. bind-chroot had strange issues at my installation, and since it's just > a chroot-tree (which most/all people running bind in a chrooted configuration > will already have), I just removed it initially. Will check it later and post > it too. > Anyway, if you need the bind-chroot, feel free to recompile it from my > src.rpm. Done that and everything went well, thank you. Reply at: https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/406122/comments/22 ------------------------------------------------------------------------ On 2009-07-29T16:55:24+00:00 thoger wrote: (In reply to comment #31) > Is there a possibility to back-port it to redhat 7.3? Dmitri, Red Hat Linux 7.3 is not supported for years, so there will be no update for it. The patch for later bind version (e.g. from RHEL3) may apply cleanly to bind in 7.3, but you'll have to do you own backport / build. Reply at: https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/406122/comments/23 ------------------------------------------------------------------------ On 2009-07-29T17:06:14+00:00 rmeikle wrote: > By default, both /etc/rndc.conf and /etc/rndc.key are mode 0640 and owned > root:named so on the DNS server itself, someone would require named or root > privileges to obtain the key; on external systems that may contain the RNDC > key > for updating, this would depend on that host's security. Maybe I'm misunderstanding...could someone please clarify? Wouldn't this imply that as long as the box is secure that no malicious attacker could send a packet since they wouldn't have the correct permissions to access the RNDC key? Reply at: https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/406122/comments/24 ------------------------------------------------------------------------ On 2009-07-29T17:08:55+00:00 thoger wrote: (In reply to comment #11) > http://www.durval.com.br/RPMS/el4/bind A note to all using Durval's packages. If you install them, you may not get official updates installed automatically due to Durval's packages having newer NVR and you may need to install them manually. Reply at: https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/406122/comments/25 ------------------------------------------------------------------------ On 2009-07-29T17:11:43+00:00 grand wrote: (In reply to comment #35) > (In reply to comment #31) > > Is there a possibility to back-port it to redhat 7.3? > > Dmitri, Red Hat Linux 7.3 is not supported for years, so there will be no > update for it. The patch for later bind version (e.g. from RHEL3) may apply > cleanly to bind in 7.3, but you'll have to do you own backport / build. Thanks for the heads up. Here's what happens when I try to build rpm from srcrpm taken from http://people.redhat.com/atkac/bind/bind-9.2.4-25.el3.src.rpm glibc-headers-2.3.2-101.4 gcc-2.96-112.7.2 gcc -O2 -g -march=i386 -mcpu=i686 -g -I/usr/src/redhat/BUILD/bind-9.2.4 -I./include -I./../pthreads/include -I../include -I./../include -I./.. -D_REENTRANT -W -Wall -Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wformat -c interfaceiter.c -fPIC -DPIC -o .libs/interfaceiter.lo In file included from include/isc/net.h:88, from interfaceiter.c:36: ../include/isc/ipv6.h:63: redefinition of `struct in6_addr' ../include/isc/ipv6.h:81: redefinition of `struct sockaddr_in6' In file included from interfaceiter.c:36: include/isc/net.h:159: redefinition of `struct in6_pktinfo' include/isc/net.h:202: warning: redefinition of `in_port_t' /usr/include/netinet/in.h:92: warning: `in_port_t' previously declared here make[3]: *** [interfaceiter.lo] Error 1 make[3]: Leaving directory `/usr/src/redhat/BUILD/bind-9.2.4/lib/isc/unix' make[2]: *** [subdirs] Error 1 make[2]: Leaving directory `/usr/src/redhat/BUILD/bind-9.2.4/lib/isc' make[1]: *** [subdirs] Error 1 make[1]: Leaving directory `/usr/src/redhat/BUILD/bind-9.2.4/lib' make: *** [subdirs] Error 1 Reply at: https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/406122/comments/26 ------------------------------------------------------------------------ On 2009-07-29T17:44:13+00:00 errata-xmlrpc wrote: This issue has been addressed in following products: Red Hat Enterprise Linux 5 Via RHSA-2009:1179 https://rhn.redhat.com/errata/RHSA-2009-1179.html Reply at: https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/406122/comments/27 ------------------------------------------------------------------------ On 2009-07-29T18:01:39+00:00 errata-xmlrpc wrote: This issue has been addressed in following products: Red Hat Enterprise Linux 4 Via RHSA-2009:1180 https://rhn.redhat.com/errata/RHSA-2009-1180.html Reply at: https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/406122/comments/28 ------------------------------------------------------------------------ On 2009-07-29T18:18:06+00:00 errata-xmlrpc wrote: This issue has been addressed in following products: Red Hat Enterprise Linux 3 Via RHSA-2009:1181 https://rhn.redhat.com/errata/RHSA-2009-1181.html Reply at: https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/406122/comments/29 ------------------------------------------------------------------------ On 2009-07-29T18:28:02+00:00 mjc wrote: We will be repushing the RHEL5 update shortly: The packages in this erratum have been updated to also correct this issue in the bind-sdb package. Reply at: https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/406122/comments/30 ------------------------------------------------------------------------ On 2009-07-29T22:56:20+00:00 errata-xmlrpc wrote: This issue has been addressed in following products: Red Hat Enterprise Linux 5 Via RHSA-2009:1179 https://rhn.redhat.com/errata/RHSA-2009-1179.html Reply at: https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/406122/comments/31 ------------------------------------------------------------------------ On 2009-07-30T00:11:04+00:00 no.spa wrote: (In reply to comment #42) > This issue has been addressed in following products: > Red Hat Enterprise Linux 4 > Via RHSA-2009:1180 https://rhn.redhat.com/errata/RHSA-2009-1180.html There are still no new rpms in http://mirror.centos.org/centos/4/updates/i386/RPMS/ when 3.x and 5.x have new bind rpms Reply at: https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/406122/comments/32 ------------------------------------------------------------------------ On 2009-07-30T03:55:21+00:00 updates wrote: bind-9.6.1-4.P1.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report. Reply at: https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/406122/comments/33 ------------------------------------------------------------------------ On 2009-07-30T03:55:35+00:00 updates wrote: bind-9.5.1-3.P3.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report. Reply at: https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/406122/comments/34 ------------------------------------------------------------------------ On 2009-07-30T05:23:34+00:00 no.spa wrote: When you will put RPMs for Red Hat Enterprise Linux 4? There are still old RPMS on http://mirror.centos.org/centos/4/updates/i386/RPMS/ Reply at: https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/406122/comments/35 ------------------------------------------------------------------------ On 2009-07-30T06:48:00+00:00 ejtr wrote: FWIW, the Debian report mentions use of the u32 iptables module to suppress packets based upon matching a bit-string, as in: iptables -A INPUT -p udp --dport 53 -j DROP -m u32 --u32 '30>>27&0xF=5' Unfortunately, the u32 module doesn't seem to exist in RHEL kernels ( and hence also CentOS ). The 32 module is mentioned in the manual, even though it doesn't exist in the kernel, BTW. After some experimentation, I've found that a partial workround is to use the string module instead searching for a single hex-byte: iptables -I INPUT -p udp --dport 53 -m string --algo kmp --from 30 --to 31 --hex-string '|28|' -j LOG --log-prefix "warning: DROPDNS: " --log-level warning Note that this string search matches on 8-bits, whereas u32 matches on 4. RFC2136 requires 3 of the other bits to be sent as zero, but ignored if non-zero. Hence there's no guarantee that an attacker might not be able to use hex-strings 29 through 2F instead, which would need 7 more iptables rules. There may be a way of expressing this via a regex, but the iptables manual is very thin on details in this regard. I also assume that string matching on every DNS packet in the kernel is probably CPU hungry, but this workround may at least provide enough medicine to keep the patient alive until the RPM update ambulance arrives. Reply at: https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/406122/comments/36 ------------------------------------------------------------------------ On 2009-07-30T07:32:54+00:00 atkac wrote: (In reply to comment #50) > FWIW, the Debian report mentions use of the u32 iptables module to suppress > packets based upon matching a bit-string, as in: > > iptables -A INPUT -p udp --dport 53 -j DROP -m u32 --u32 '30>>27&0xF=5' > > Unfortunately, the u32 module doesn't seem to exist in RHEL kernels ( and > hence > also CentOS ). The 32 module is mentioned in the manual, even though it > doesn't > exist in the kernel, BTW. > > After some experimentation, I've found that a partial workround is to use the > string module instead searching for a single hex-byte: > > iptables -I INPUT -p udp --dport 53 -m string --algo kmp --from 30 --to 31 > --hex-string '|28|' -j LOG --log-prefix "warning: DROPDNS: " --log-level > warning > > Note that this string search matches on 8-bits, whereas u32 matches on 4. > RFC2136 requires 3 of the other bits to be sent as zero, but ignored if > non-zero. Hence there's no guarantee that an attacker might not be able to use > hex-strings 29 through 2F instead, which would need 7 more iptables rules. > There may be a way of expressing this via a regex, but the iptables manual is > very thin on details in this regard. > > I also assume that string matching on every DNS packet in the kernel is > probably CPU hungry, but this workround may at least provide enough medicine > to > keep the patient alive until the RPM update ambulance arrives. This is protection against UDP based queries only. TCP based queries will still knock down your named. Reply at: https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/406122/comments/37 ------------------------------------------------------------------------ On 2009-07-30T08:13:34+00:00 thoger wrote: (In reply to comment #37) > Maybe I'm misunderstanding...could someone please clarify? Wouldn't this > imply > that as long as the box is secure that no malicious attacker could send a > packet since they wouldn't have the correct permissions to access the RNDC > key? Comment #20 has update for the initial description. Further investigation proved that the broken code is reachable even with update request packet that is not signed (hence attacked does not need to know key configured on the server) and even if bind is not configured for dynamic updates. Reply at: https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/406122/comments/38 ------------------------------------------------------------------------ On 2009-07-30T08:14:57+00:00 thoger wrote: (In reply to comment #39) > Here's what happens when I try to build rpm from srcrpm taken from > http://people.redhat.com/atkac/bind/bind-9.2.4-25.el3.src.rpm My though was more about taking SRPM from 7.3 and adding patch extracted from RHEL3 SRPM to it. Though there may be other unfixed security flaws form the past as well. Reply at: https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/406122/comments/39 ------------------------------------------------------------------------ On 2009-07-30T08:18:22+00:00 thoger wrote: (In reply to comment #49) > When you will put RPMs for Red Hat Enterprise Linux 4? There are still old > RPMS > on http://mirror.centos.org/centos/4/updates/i386/RPMS/ Red Hat Enterprise Linux 4 updates are available via Red Hat Network, SRPM are also available on FTP: ftp://updates.redhat.com/enterprise/4AS/en/os/SRPMS/ Only CentOS team can tell when corresponding CentOS updates for CentOS 4 will be available. You can watch centos-announce list for updates: http://lists.centos.org/mailman/listinfo/centos-announce Reply at: https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/406122/comments/40 ------------------------------------------------------------------------ On 2009-07-31T03:52:31+00:00 grand wrote: (In reply to comment #53) > (In reply to comment #39) > My though was more about taking SRPM from 7.3 and adding patch extracted from > RHEL3 SRPM to it. Though there may be other unfixed security flaws form the > past as well. I was able to successfully patch bind-9.2.1-1.7x.2.src.rpm using contents of bind-9.2.4-CVE-2009-0696.diff from bind-9.2.4-25.el3.src.rpm Resulting package seems stable and fixes this particular flaw. Reply at: https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/406122/comments/41 ------------------------------------------------------------------------ On 2009-09-08T08:07:49+00:00 malek.shabou wrote: (In reply to comment #54) > (In reply to comment #49) > > When you will put RPMs for Red Hat Enterprise Linux 4? There are still old > > RPMS > > on http://mirror.centos.org/centos/4/updates/i386/RPMS/ > > Red Hat Enterprise Linux 4 updates are available via Red Hat Network, SRPM are > also available on FTP: > > ftp://updates.redhat.com/enterprise/4AS/en/os/SRPMS/ > > Only CentOS team can tell when corresponding CentOS updates for CentOS 4 will > be available. You can watch centos-announce list for updates: > > http://lists.centos.org/mailman/listinfo/centos-announce since it updated, BIND stop responding to requests IPv6 regularly. we have found these errors: Sep 1 04:02:01 tree named[8364]: client.c:1334: unexpected error: Sep 1 04:02:06 tree named[8364]: client.c:1334: unexpected error: Sep 1 04:02:11 tree named[8364]: client.c:1334: unexpected error: At 04:02 AM logrotate execute '/sbin/service named reload 2> /dev/null > /dev/null || true' it seems that there is a link between the reload and the probleme Regards, Reply at: https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/406122/comments/42 ------------------------------------------------------------------------ On 2009-09-08T12:48:49+00:00 atkac wrote: (In reply to comment #57) > since it updated, BIND stop responding to requests IPv6 regularly. we have > found these errors: > Sep 1 04:02:01 tree named[8364]: client.c:1334: unexpected error: > Sep 1 04:02:06 tree named[8364]: client.c:1334: unexpected error: > Sep 1 04:02:11 tree named[8364]: client.c:1334: unexpected error: It seems you are affected by bug #518866. Reply at: https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/406122/comments/43 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/406122 Title: BIND Dynamic Update DoS To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/406122/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
