A BIND 9 DNS server set up to be a caching resolver is vulnerable to a user querying a domain with very large resource record sets (RRSets) when trying to negatively cache a response. This can cause the BIND 9 DNS server (named process) to crash.
9.4-ESV-R3 and later, 9.6-ESV-R2 and later, 9.6.3, 9.7.1 and later, 9.8.0 and later
Upgrade to: 9.4-ESV-R4-P1, 9.6-ESV-R4-P1, 9.7.3-P1 or 9.8.0-P2:
I just added 9.7.3_p1 and 9.8.0_p2.
Arches, please test and mark stable:
Target keywords : "alpha amd64 arm hppa ia64 ppc ppc64 s390 sh sparc x86"
>>> Preparing source in /tmp/portage/net-dns/bind-9.7.3_p1/work/bind-9.7.3-P1 ...
* Applying bind-dlzmysql5-reconnect.patch ...
[ ok ]
* Cannot find $EPATCH_SOURCE! Value for $EPATCH_SOURCE is:
* ( bind-9.7.3_p1-odbc-dlz-detect.patch )
* ERROR: net-dns/bind-9.7.3_p1 failed (prepare phase):
* Cannot find $EPATCH_SOURCE!
* Call stack:
* ebuild.sh, line 56: Called src_prepare
* environment, line 3280: Called epatch '/usr/portage/net-dns/bind/files/bind-9.7.3_p1-odbc-dlz-detect.patch
Fixed in CVS, sorry.
looks ok on my server. amd64 done
Stable for HPPA.
Thanks, everyone. GLSA Vote: yes.
Off-by-one error in named in ISC BIND 9.x before 9.7.3-P1, 9.8.x before
9.8.0-P2, 9.4-ESV before 9.4-ESV-R4-P1, and 9.6-ESV before 9.6-ESV-R4-P1
allows remote DNS servers to cause a denial of service (assertion failure
and daemon exit) via a negative response containing large RRSIG RRsets.
Vote: YES. Added to pending GLSA request.
This issue was resolved and addressed in
GLSA 201206-01 at http://security.gentoo.org/glsa/glsa-201206-01.xml
by GLSA coordinator Stefan Behte (craig).