Your message dated Sun, 5 Dec 2010 02:29:24 -0700
with message-id <[email protected]>
and subject line Re: Bug#605876: BIND 9.7.2-P3 (CVE-2010-3613, CVE-2010-3614
and CVE-2010-3615)
has caused the Debian Bug report #605876,
regarding BIND 9.7.2-P3 (CVE-2010-3613, CVE-2010-3614 and CVE-2010-3615)
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
605876: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=605876
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: bind9
Severity: grave
Tags: security
Hi,
Upstream has released BIND 9.7.2-P3, it includes bug and security fixes,
assigned as CVE-2010-3613, CVE-2010-3614 and CVE-2010-3615.
Please consider to update bind9.
For detail, see
http://ftp.isc.org/isc/bind9/9.7.2-P3/RELEASE-NOTES-BIND-9.7.2-P3.html#id36112448
> * Adding a NO DATA signed negative response to cache failed to clear
> any matching RRSIG records already in cache. A subsequent lookup of
> the cached NO DATA entry could crash named (INSIST) when the
> unexpected RRSIG was also returned with the NO DATA cache entry.
> [RT #22288] [CVE-2010-3613] [VU#706148]
> * BIND, acting as a DNSSEC validator, was determining if the NS RRset
> is insecure based on a value that could mean either that the RRset
> is actually insecure or that there wasn't a matching key for the
> RRSIG in the DNSKEY RRset when resuming from validating the DNSKEY
> RRset. This can happen when in the middle of a DNSKEY algorithm
> rollover, when two different algorithms were used to sign a zone
> but only the new set of keys are in the zone DNSKEY RRset. [RT
> #22309] [CVE-2010-3614] [VU#837744]
> * When BIND is running as an authoritative server for a zone and
> receives a query for that zone data, it first checks for
> allow-query acls in the zone statement, then in that view, then in
> global options. If none of these exist, it defaults to allowing any
> query (allow-query {"any"};).
> With this bug, if the allow-query is not set in the zone statement,
> it failed to check in view or global options and fell back to the
> default of allowing any query. This means that queries that the
> zone owner did not wish to allow were incorrectly allowed. [RT
> #22418] [CVE-2010-3615] [VU#510208]
--
Regards,
Hideki Yamane henrich @ debian.or.jp/org
http://wiki.debian.org/HidekiYamane
--- End Message ---
--- Begin Message ---
fixed 1:9.7.2.dfsg.P3-1
--
lamont
--- End Message ---
