Re: Bug in bind 9.7.3?
This is reproducible and should only affected in 9.7.3. For the record, the problem has been fixed: http://www.isc.org/software/bind/advisories/cve-2011-1910 -JP ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
BIND Security Advisory May 2011: Large RRSIG RRsets and Negative Caching can crash named
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 *Summary:* 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. *Document ID:* CVE-2011-1910 *Document Status:* Draft *Posting date:* 26 May 2011 *Program Impacted:* BIND *Versions affected:* 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 *Severity:* High *Exploitable:* Remotely *CVSS Score:* Base 7.8 (AV:N/AC:L/Au:N/C:N/I:N/A:C) For more information on the Common Vulnerability Scoring System and to obtain your specific environmental score please visit: http://nvd.nist.gov/cvss.cfm?calculatoradvversion=2 *Description:* DNS systems use negative caching to improve DNS response time. This will keep a DNS resolver from repeatedly looking up domains that do not exist. Any NXDOMAIN or NODATA/NOERROR response will be put into the negative cache. The authority data will be cached along with the negative cache information. These authoritative ?Start of Authority? (SOA) and NSEC/NSEC3 records prove the nonexistence of the requested name/type. In DNSSEC, all of these records are signed; this adds one additional RRSIG record, per DNSSEC key, for each record returned in the authority section of the response. In this vulnerability, very large RRSIG RRsets included in a negative cache can trigger an assertion failure that will crash named (BIND 9 DNS) due to an off-by-one error in a buffer size check. The nature of this vulnerability would allow remote exploit. An attacker can set up an DNSSEC signed authoritative DNS server with a large RRSIG RRsets to act as the trigger. The attacker would then find ways to query an organization?s caching resolvers, using the negative caches and the ?trigger? the vulnerability. The attacker would require access to an organization?s caching resolvers. Access to the resolvers can be direct (open resolvers), through malware (using a BOTNET to query negative caches), or through driving DNS resolution (a SPAM run that has a domain in the E-mail that will cause the client to do look up a negative cache). *Workarounds:* Restricting access to the DNS caching resolver infrastructure will provide partial mitigation. Active exploitation can be accomplished through malware or SPAM/Malvertizing actions that will force authorized clients to look up domains that would trigger this vulnerability. *Solution:* Upgrade to: 9.4-ESV-R4-P1, 9.6-ESV-R4-P1, 9.7.3-P1 or 9.8.0-P2 ftp://ftp.isc.org/isc/bind9/9.8.0-P2 ftp://ftp.isc.org/isc/bind9/9.7.3-P1 ftp://ftp.isc.org/isc/bind9/9.6-ESV-R4-P1 BIND 9.4 is less vulnerable than other versions, and a patched version will be available on May 27th at ftp://ftp.isc.org/isc/bind9/9.4-ESV-R4-P1 *Exploit Status:* High. This issue has caused un-intentional outages. US CERT is tracking this issue with INC00152411. *Credits:* Thanks to Frank Kloeker and Michael Sinatra for getting the details to this issue to the DNS Operations community and to Michael Sinatra, Team Cmyru, and other community members for testing. Questions regarding this advisory shoud go to security-offi...@isc.org mailto:security-offi...@isc.org. Questions on ISC's Support services or other offerings should be sent to i...@isc.org mailto:dhcp-b...@isc.org More information on ISC's support and other offerings are available at:http://www.isc.org/community/blog/201102/BIND-support - -- Larissa Shapiro Internet Systems Consortium Product Manager Technology Leadership for the Common Good +1 650 423 1335 www.isc.org -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJN3zgqAAoJEBOIp87tasiU0RgH/1eOHonKvvh3gcAfzzhWezNr 0X+ERXldJnylLYUrVPoVdzFXCsKkReY6qrTDUJnO6qvB62oYQNfZnO21fkM17m6Z wA/HTnnu5YlnmHZQVabCJptLWsJ7nGwFygKdwgJbu/npWmSaEoKgNWIdcWbnVlm6 xk9XXdjc25rJLIqTgXXWWnyAsFc0SvNomOFd2zkuPsa7vuJczpdWw1Rdn9TP1vOo BF1gS2GR7O9ewghTQGXCAcNNdezconkE7moxTZx6y8qGGyP8nvfRwGWneXKjy49r 8rY1ABo92rly60E8uCs4S8tiFQxTlwWsGBfyREk0SClvT1PFDM+Yz11U/FmBG2E= =QKvu -END PGP SIGNATURE- ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Why DNSSEC errors for bund.de?
To follow up on this thread (there's been much more about it on DNS-OARC than here), it was a bug that is fixed (change 3020) together with the more serious security problem (change 3121) in the new BIND versions 9.6-ESV-R4-P1, 9.7.3-P1 and 9.8.0-P2. -- Chris Thompson Email: c...@cam.ac.uk ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Updated Security Advisory: BIND 9.4-ESV-R4-P1 is now available.
Change: BIND 9.4-ESV-R4-P1 is now available. Title: Large RRSIG RRsets and Negative Caching can crash named. Summary: 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. Document ID: CVE-2011-1910 Posting date: 26 May 2011 Program Impacted: BIND Versions affected: 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 Severity: High Exploitable: Remotely CVSS Score: Base 7.8 (AV:N/AC:L/Au:N/C:N/I:N/A:C) For more information on the Common Vulnerability Scoring System and to obtain your specific environmental score please visit: http://nvd.nist.gov/cvss.cfm?calculatoradvversion=2 Description: DNS systems use negative caching to improve DNS response time. This will keep a DNS resolver from repeatedly looking up domains that do not exist. Any NXDOMAIN or NODATA/NOERROR response will be put into the negative cache. The authority data will be cached along with the negative cache information. These authoritative Start of Authority (SOA) and NSEC/NSEC3 records prove the nonexistence of the requested name/type. In DNSSEC, all of these records are signed; this adds one additional RRSIG record, per DNSSEC key, for each record returned in the authority section of the response. In this vulnerability, very large RRSIG RRsets included in a negative cache can trigger an assertion failure that will crash named (BIND 9 DNS) due to an off-by-one error in a buffer size check. The nature of this vulnerability would allow remote exploit. An attacker can set up an DNSSEC signed authoritative DNS server with a large RRSIG RRsets to act as the trigger. The attacker would then find ways to query an organization's caching resolvers, using the negative caches and the trigger the vulnerability. The attacker would require access to an organization's caching resolvers. Access to the resolvers can be direct (open resolvers), through malware (using a BOTNET to query negative caches), or through driving DNS resolution (a SPAM run that has a domain in the E-mail that will cause the client to do look up a negative cache). Workarounds: Restricting access to the DNS caching resolver infrastructure will provide partial mitigation. Active exploitation can be accomplished through malware or SPAM/Malvertizing actions that will force authorized clients to look up domains that would trigger this vulnerability. Solution: Upgrade to: 9.4-ESV-R4-P1, 9.6-ESV-R4-P1, 9.7.3-P1 or 9.8.0-P2 ftp://ftp.isc.org/isc/bind9/9.8.0-P2 ftp://ftp.isc.org/isc/bind9/9.7.3-P1 ftp://ftp.isc.org/isc/bind9/9.6-ESV-R4-P1 ftp://ftp.isc.org/isc/bind9/9.4-ESV-R4-P1 Exploit Status: High. This issue has caused unintentional outages. US CERT is tracking this issue with INC00152411. Credits: Thanks to Frank Kloeker and Michael Sinatra for getting the details to this issue to the DNS Operations community and to Michael Sinatra, Team Cmyru, and other community members for testing. Revision History: Added the 9.4-ESV-R4-P1 download. 2011-May-27 Questions regarding this advisory should go to security-offi...@isc.org. Questions on ISC's Support services or other offerings should be sent to sa...@isc.org. More information on ISC's support and other offerings are available at: http://www.isc.org/community/blog/201102/BIND-support -- Larissa Shapiro Internet Systems Consortium Product Manager Technology Leadership for the Common Good +1 650 423 1335 www.isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
? bad cache hit (eduftcdnsp01.ed.gov/DS)
Hi, Running BIND 9.7.0-P2 Is this just me or other seeing this? Starting today got reports of unable to reach some student ad sites such as studentloans.gov # dig eduftcdnsp01.ed.gov ; DiG 9.7.0-P2-RedHat-9.7.0-5.P2.el6_0.1 eduftcdnsp01.ed.gov ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: SERVFAIL, id: 46012 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;eduftcdnsp01.ed.gov. IN A ;; Query time: 550 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Fri May 27 15:06:00 2011 ;; MSG SIZE rcvd: 37 ~in dnssec log file; 27-May-2011 15:06:00.097 dnssec: info: validating @0x7ff40c023520: eduftcdnsp01.ed.gov A: bad cache hit (eduftcdnsp01.ed.gov/DS) With the checking disabled; # dig eduftcdnsp01.ed.gov +cd ; DiG 9.7.0-P2-RedHat-9.7.0-5.P2.el6_0.1 eduftcdnsp01.ed.gov +cd ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 11700 ;; flags: qr rd ra cd; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 0 ;; QUESTION SECTION: ;eduftcdnsp01.ed.gov. IN A ;; ANSWER SECTION: eduftcdnsp01.ed.gov.3539IN A 148.9.101.50 ;; AUTHORITY SECTION: ed.gov. 2777IN NS eduptcdnsp01.ed.gov. ed.gov. 2777IN NS eduptcdnsp02.ed.gov. ed.gov. 2777IN NS eduftcdnsp02.ed.gov. ed.gov. 2777IN NS eduftcdnsp01.ed.gov. ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Fri May 27 15:07:01 2011 ;; MSG SIZE rcvd: 148 thanks! jim ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: ? bad cache hit (eduftcdnsp01.ed.gov/DS)
On Fri, May 27, 2011 at 12:09 PM, Jim Glassford jmgl...@iup.edu wrote: Starting today got reports of unable to reach some student ad sites such as studentloans.gov There are problems with this and related sites. Specifically RRSIGs are not being returned with some RRsets, resulting in a broken chain of trust and a bogus validation status: http://dnsviz.net/d/studentloans.gov/dnssec/ http://dnsviz.net/d/eduftcdnsp01.ed.gov/dnssec/ There's been some effort through this list and other DNS lists to contact the DNS admins of these sites and make them aware of the problems, so they can be resolved. Regards, Casey ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: ? bad cache hit (eduftcdnsp01.ed.gov/DS)
Hi Jim, We are seeing the same thing. The problem is an incorrectly signed zone (missing RRSIG records) at ed.gov. See: http://dnssec-debugger.verisignlabs.com/www.ed.gov http://dnsviz.net/d/www.ed.gov/dnssec/ cv On Fri, May 27, 2011 at 12:09 PM, Jim Glassford jmgl...@iup.edu wrote: Hi, Running BIND 9.7.0-P2 Is this just me or other seeing this? Starting today got reports of unable to reach some student ad sites such as studentloans.gov # dig eduftcdnsp01.ed.gov ; DiG 9.7.0-P2-RedHat-9.7.0-5.P2.el6_0.1 eduftcdnsp01.ed.gov ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: SERVFAIL, id: 46012 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;eduftcdnsp01.ed.gov. IN A ;; Query time: 550 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Fri May 27 15:06:00 2011 ;; MSG SIZE rcvd: 37 ~in dnssec log file; 27-May-2011 15:06:00.097 dnssec: info: validating @0x7ff40c023520: eduftcdnsp01.ed.gov A: bad cache hit (eduftcdnsp01.ed.gov/DS) With the checking disabled; # dig eduftcdnsp01.ed.gov +cd ; DiG 9.7.0-P2-RedHat-9.7.0-5.P2.el6_0.1 eduftcdnsp01.ed.gov +cd ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 11700 ;; flags: qr rd ra cd; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 0 ;; QUESTION SECTION: ;eduftcdnsp01.ed.gov. IN A ;; ANSWER SECTION: eduftcdnsp01.ed.gov. 3539 IN A 148.9.101.50 ;; AUTHORITY SECTION: ed.gov. 2777 IN NS eduptcdnsp01.ed.gov. ed.gov. 2777 IN NS eduptcdnsp02.ed.gov. ed.gov. 2777 IN NS eduftcdnsp02.ed.gov. ed.gov. 2777 IN NS eduftcdnsp01.ed.gov. ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Fri May 27 15:07:01 2011 ;; MSG SIZE rcvd: 148 thanks! jim ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND Security Advisory May 2011: Large RRSIG RRsets and Negative Caching can crash named
On Fri, 27 May 2011, Frank Kloeker wrote: Hello, I would want to say thank you very much for the wonderful work of the ISC team and the quick solution of the problem and a very professional appearance. I have come to expect such performance from everyone at ISC, but yesterday the exceeded even those high expectations. Hats off to a great job by a talented group of people who takes their role in the Internet very seriously. michael ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Bug in bind 9.7.3?
Evan Hunt wrote: Yes. But the problem domain has been corrected, so you won't be able to reproduce it now. In the interest of preventing this happening again, either by accident (as it was in this case) or due to someone crafting a bad zone maliciously, we will be releasing a patch to all affected versions of BIND 9 as soon as I finish turning the crank. Thanks for letting me know. I should have written this last night after reading your email, but I went to bed, and upgraded all our nameservers in the morning instead :-) I must say - ISC dealt with this issue much faster than I'd have expected really. No, I'm not saying I'd have expected you to take ages, but hopefully you know what I'm trying to say here. Keep up the good work! -- Regards Eivind Olsen eiv...@aminor.no ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
