- dns-wg - mailman.ripe.net

Vulnerability Issues in Implementations of the DNS Protocol
by Roy Arends 03 May '06

03 May '06

With all the lies and statistics going on, this vulnerability advisory from NISCC might have slipped by. Since the url points to a pdf file, I took the liberty to convert this. Roy. -------- http://www.niscc.gov.uk/niscc/docs/re-20060425-00312.pdf?lang=en NISCC Vulnerability Advisory 144154/NISCC/DNS Vulnerability Issues in Implementations of the DNS Protocol Version Information Advisory Reference 144154/NISCC/DNS Release Date 25 April 2006 Last Revision 02 May 2006 Version Number 1.2 Acknowledgement The DNS Test Tool was created by the Oulu University Secure Programming Group (OUSPG) from the University of Oulu in Finland. What is Affected? The vulnerabilities described in this advisory affect implementations of the Domain Name System (DNS) protocol. Many vendors include support for this protocol in their products and may be impacted to varying degrees, if at all. Impact If exploited, these vulnerabilities could cause a variety of outcomes including, for example, a Denial-of-Service (DoS) condition. In most cases, they can expose memory corruption, stack corruption or other types of fatal error conditions. Some of these conditions may expose the protocol to typical buffer overflow exploits, allowing arbitrary code to execute or the system to be modified. Severity The severity of this vulnerability varies by vendor. Please see the 'Vendor Information' section below for further information. Alternatively, contact your vendor for product specific information. Summary During 2002 the Oulu University Secure Programming Group (OUSPG) discovered a number of implementation specific vulnerabilities in the Simple Network Management Protocol (SNMP). Further work has been done to identify implementation specific vulnerabilities in related protocols that are used in critical infrastructure. The DNS protocol, which is the primary naming system used on the Internet, was studied as part of this program of work. DNS is an Internet service that translates domain names into Internet Protocol (IP) addresses and vice versa. Because domain names are alphabetic, they're easier to remember, however the Internet is really based on IP addresses; therefore every time a domain name is requested, a DNS service must translate the name into the corresponding IP address. OUSPG has developed a PROTOS DNS Test Suite for DNS implementations and employed it to validate their findings against a number of products from different vendors. NISCC has contacted multiple vendors whose products support the DNS protocol and provided them with the test tool to allow them to test their implementations. NISCC believes that most of the relevant vendors who provide support for the DNS protocol have been covered by this advisory. Details DNS is a system that stores information associated with domain names in a distributed database on networks such as the Internet. The domain name system associates many types of information with domain names, but most importantly, it provides the IP address associated with the domain name. It also lists mail exchange servers accepting e-mail for each domain and a wide variety of other records. The OUSPG DNS Test Suite covers a limited set of information security and robustness related implementation errors for the DNS protocol. The factors behind choosing DNS included: DNS is a fundamental infrastructure of the Internet, most Internet applications are dependent on it. DNS implementations are ubiquitous: present in servers, end- user equipment such as personal computers or mobile phones and in routers and firewalls. Therefore DNS may be a potential attack vector in a variety of scenarios against a variety of systems and infrastructure components. There are no free, publicly available robustness test suites to evaluate DNS implementations. The material contained in the test suite covers basic queries, dynamic updates, basic responses and zone transfers. However please be aware that the test material does not cover cache poisoning or address spoofing vulnerabilities. There are three sets of test materials available with the tool; these are specifically designed for the following scenarios: 1. The Query Material -> [queries, dynamic DNS updates] -> DNS server 2. The Response Material -> [query replies] -> DNS server 3. The Response Material -> [query replies] -> DNS stub resolver (client) 4. The Zone Transfer Material -> [zone transfers] -> secondary DNS server The test material simulates hostile input to the DNS implementation by sending invalid and/or abnormal packets. Therefore by applying the OUSPG DNS Test Suite to a variety of products, several vulnerabilities can be revealed that can have varying effects. Mitigation Patch all affected implementations. Solution Please refer to the 'Vendor Information' section of this advisory for platform specific remediation. Vendor Information The following vendors have provided information about how their products are affected by this vulnerability. Please note that JPCERT/CC have released a Japanese language advisory for this vulnerability which contains additional information regarding Japanese vendors. This advisory is available at http://jvn.jp/niscc/NISCC-144154/index.html Cisco Systems, Inc Microsoft Delegate MyDNS Ethereal pdnsd Fujitsu Sun Hitachi Wind River ISC Juniper Networks Cisco Systems, Inc Cisco Systems is currently testing its DNS related products. We will provide updates if warranted at http://www.cisco.com/go/psirt. Delegate Vulnerable: DeleGate/9.0.5 (DEVELOPMENT) and prior versions DeleGate/8.11.5 (STABLE) and prior versions Not Vulnerable: DeleGate/9.0.6 and subsequent versions DeleGate/8.11.6 and subsequent versions DeleGate is an application level gateway (proxy server) which relays multiple application protocols including HTTP, FTP, SMTP, SOCKS, DNS; running on Unix and Windows. There have been bugs in its DNS protocol handling unit where a DNS response message is analyzed. Due to this problem, DeleGate can suffer a denial-of-service attack. For some crafted or broken response messages, it reads the message data area beyond the real size of it, or read it in infinitely recursive function call. Then the DeleGate process will abort causing segmentation fault or so accessing non-existent address or non-available memory. DeleGate as DNS proxy, ICP server and UDP-relay might stop their service receiving such broken DNS response, since the abortion occurs in the main process which is not to be restarted automatically by itself. Other DeleGate proxies for other protocols do not stop servicing but a child process for a session might abort without returning response message of each application protocol. These bugs have been fixed in version 9.0.6 (development version) and 8.11.6 (stable version). The impact for resent versions is not more than DoS, but upgrading to these versions (or subsequent ones) is recommended. The impact can be more serious in ancient versions of DeleGate prior to 8.10.3 which also include many other kind of dangers (http://www.delegate.org/mail- lists/delegate-en/2793), so they must be upgraded anyway. Ethereal The Ethereal development team is investigating the reported vulnerabilities to determine if any versions of Ethereal are affected. We will provide updated status information in the near future. Fujitsu Fujitsu have provided more information on this issue at the following location (in Japanese): http://software.fujitsu.com/jp/security/vulnerabilities/niscc144154.html Hitachi Hitachi believe that the AlaxalA Networks AX series, Hitachi GR2000/GR4000/GS4000/GS3000 and Hitachi HI-UX are NOT vulnerable to this issue. ISC ISC has reviewed a bug that can cause named to terminate abnormally if a broken TSIG is present in the second or later message of a zone transfer. However, this is not considered high-risk as the first message must have a correct TSIG present for the transaction to continue. A fix will be included in a future BIND release. Juniper Networks The OUSPG PROTOS c09-dns-response test tool was run against all Juniper Networks platforms. JUNOS and ScreenOS were unaffected. Tests against JUNOSe, found on the E-series routers, did result in an issue with the DNS client code (ref: KA 23381). The issue was resolved in the following JUNOSe updates: 5-3-5p0-2, 6-0-3p0-6, 6-0-4, 6-1-3p0-1, 7-0-1p0-7, 7-0-2, 7-1-0p0- 1, 7-1-1. Later JUNOSe releases are unaffected. Microsoft Microsoft are still testing their products and will provide an update when more information is available. MyDNS MyDNS 1.1.0 has been released which contains a fix for a query-of-death DoS bug uncovered by the test suite. New versions can be obtained from: http://mydns.bboy.net/ pdnsd The current maintainer of the pdnsd project, Paul A. Rombouts, has run tests on pdnsd with the DNS Test Suite mentioned here and discovered one significant flaw in the pdnsd code, which affects several versions of pdnsd. A DNS query with an unsupported QTYPE or QCLASS can cause pdnsd to leak memory. The amount of memory used by pdnsd may thus grow continually and unbounded and may eventually cause pdnsd to crash or cause the system to become sluggish and unresponsive. All users of pdnsd are advised to upgrade to version 1.2.4 or later of pdnsd, which has a fix for this leak and is available at: http://www.phys.uu.nl/~rombouts/pdnsd.html Sun Sun Microsystems is currently investigating the impact of the OUSPG DNS test suite to Sun's products. If any issues are identified, Sun will publish Sun Alerts which will include details of the impact and suggested resolution for those issues. Wind River Wind River does not believe that any of the products we provide are currently vulnerable to the issues described in this Vulnerability Notice. Acknowledgements The NISCC Vulnerability Management Team would like to thank OUSPG for producing the DNS Test Tool. The NISCC Vulnerability Management Team would also like to thank the vendors for their co-operation in handling this vulnerability and to JPCERT/CC for co-ordinating this issue in Japan. Contact Information The NISCC Vulnerability Management Team can be contacted as follows: Email vulteam(a)niscc.gov.uk (Please quote the advisory reference in the subject line.) Telephone +44 (0)870 487 0748 Extension 4511 (Monday to Friday 08:30 - 17:00) Fax +44 (0)870 487 0749 Post Vulnerability Management Team NISCC PO Box 832 London SW1P 1BG We encourage those who wish to communicate via email to make use of our PGP key. This is available from http://www.niscc.gov.uk/niscc/publicKey2-en.pop. Please note that UK government protectively marked material should not be sent to the email address above. If you wish to be added to our email distribution list, please email your request to uniras(a)niscc.gov.uk. What is NISCC? For further information regarding the UK National Infrastructure Security Co-Ordination Centre, please visit the NISCC web site at: http://www.niscc.gov.uk/ Reference to any specific commercial product, process or service by trade name, trademark manufacturer or otherwise, does not constitute or imply its endorsement, recommendation, or favouring by NISCC. The views and opinions of authors expressed within this notice shall not be used for advertising or product endorsement purposes. Neither shall NISCC accept responsibility for any errors or omissions contained within this advisory. In particular, they shall not be liable for any loss or damage whatsoever, arising from or in connection with the usage of information contained within this notice. © 2006 Crown Copyright Revision History 25 April 2006 Initial release (1.0) 26 April 2006 Added Vendor Statement from Cisco (1.1) 02 May 2006 Added Vendor Statement from Fujitsu (1.2) <End of NISCC Vulnerability Advisory> http://www.niscc.gov.uk/niscc/docs/re-20060425-00312.pdf?lang=en

1 0

"DNS Vulnerabilities" paper hits the mainstream
by Jim Reid 02 May '06

02 May '06

Emin Gun Sirer's paper/presentation at RIPE52 has been picked up by the BBC: http://news.bbc.co.uk/1/hi/technology/4954208.stm Any thoughts on how to respond to that?

10 11

DRAFT DNS WG Meeting Agenda for RIPE 52
by Peter Koch 20 Apr '06

20 Apr '06

Dear DNS WG, here's an updated draft agenda for the upcoming meetings on Thursday next week. Changes include an extra slot for discussion of K-Root anycast. DNSSEC status updates were merged into the general reports item. -Peter # $Id: RIPE52agenda,v 1.6 2006/04/20 11:14:44 pk Exp $ ############################################################################# D R A F T ############################################################################# DNS-related presentations in the EOF/plenary: TUE, 2006-04-25: Reflector Attacks Using DNS Infrastructure (Joao Damas) DNS amplification attacks (Matsuzaki Yoshinobu) Security Issues in ENUM (Gerhard Schröder) WED, 2006-04-26: Perils of Transitive Trust in the Domain Name System (Emin Gun Sirer) The Impact of anycast on Root DNS Servers. The Case of K-root (Lorenzo Colitti) DNS in Turkey (Attila Ozgit) ############################################################################# 2006-04-27 1100 - 1230, DNS WG slot I [90 min] ############################################################################# 0) Administrivia [chairs][ 5 min] - scribe, jabber, minutes - agenda bashing 1) Status Reports [][30 min] - IETF dnsext, dnsop and others [Olaf Kolkman][18 min] - IANA Overview [David Conrad][ 7 min] - DNSSEC News/Statistics from the NCC [][ 5min] 2) Action Item Review [chairs][15 min] <http://www.ripe.net/ripe/wg/dns/dns-actions.html> 48.1 48.2 49.1 49.2 51.1: see (3) and plenary presentation on K-root 51.2: see (4) 51.3: see also <http://www.ripe.net/news/review-secondary-dns.html> 51.4 51.5: see (6) 3) Anycast on K-Root [Lorenzo Colitti, RIPE NCC][10 min] 4) IP6.INT phase out [Andrei Robachevski, RIPE NCC][10 min] 5) Reverse DNS Quality [Brian Riddle, RIPE NCC][10 min] 6) Proposal to bring ENUM Zone Management in line with the Reverse DNS [N.N., RIPE NCC][10 min] ############################################################################# 2006-04-27 1600 - 1700, DNS WG slot II [60 min] ############################################################################# 7) Plenaries Followup [chairs][15 min] Discussion of details postponed from plenary presentations (see above), including identification of potential work for the WG 8) ICANN IDN guidelines & IDN Future [Marcos Sanz][20 min] <http://www.icann.org/topics/idn/implementation-guidelines.htm> [may also touch draft-iab-idn-nextsteps-05.txt] 9) Nominet's Dynamic Updates [Jay Daley][15 min] X) I/O with other WGs [chairs][ 4 min] Y) A.O.B. [chairs][ 4 min] Z) Wrap-Up & Close [chairs][ 2 min] #############################################################################

1 0

Oluf Nielsen is out of the office.
by Oluf Nielsen 14 Apr '06

14 Apr '06

I will be out of the office starting 10-04-2006 and will not return until 18-04-2006. I will respond to your message when I return.

1 0

DRAFT Meeting Agenda for RIPE 52
by Peter Koch 13 Apr '06

13 Apr '06

Dear WG, find below the draft agenda for our two sessions during the upcoming meeting in Istanbul. Please send comments to the chairs. -Peter # $Id: RIPE52agenda,v 1.5 2006/04/13 15:06:05 pk Exp $ ############################################################################# D R A F T ############################################################################# DNS-related presentations in the EOF/plenary: TUE, 2006-04-25: Reflector Attacks Using DNS Infrastructure (Joao Damas) DNS amplification attacks (Matsuzaki Yoshinobu) Security Issues in ENUM (Gerhard Schröder) WED, 2006-04-26: Perils of Transitive Trust in the Domain Name System (Emin Gun Sirer) The Impact of anycast on Root DNS Servers. The Case of K-root (Lorenzo Colitti) DNS in Turkey (Attila Ozgit) ############################################################################# 2006-04-27 1100 - 1230, DNS WG slot I [90 min] ############################################################################# 0) Administrivia [chairs][ 5 min] - scribe, jabber, minutes - agenda bashing 1) Status Reports [][25 min] - IETF dnsext, dnsop and others [Olaf Kolkman][18 min] - IANA Overview [David Conrad][ 7 min] 2) DNSSEC Status and Deployment Reports [][20 min] - SE Experiences [][] - DNSSEC Deployment WG [][] - News/Statistics from the NCC [][] - Other 3) Action Item Review [chairs][10 min] <http://www.ripe.net/ripe/wg/dns/dns-actions.html> 48.1 48.2 49.1 49.2 51.1: see plenary presentation on K-root 51.2: see (4) 51.3: see also <http://www.ripe.net/news/review-secondary-dns.html> 51.4 51.5: see (6) 4) IP6.INT phase out [Andrei Robachevski, RIPE NCC][10 min] 5) Reverse DNS Quality [Brian Riddle, RIPE NCC][10 min] 6) Proposal to bring ENUM Zone Management in line with the Reverse DNS [N.N., RIPE NCC][10 min] ############################################################################# 2006-04-27 1600 - 1700, DNS WG slot II [60 min] ############################################################################# 7) Plenaries Followup [chairs][15 min] Discussion of details postponed from plenary presentations (see above), including identification of potential work for the WG 8) ICANN IDN guidelines & IDN Future [Marcos Sanz][20 min] <http://www.icann.org/topics/idn/implementation-guidelines.htm> [may also touch draft-iab-idn-nextsteps-XX.txt] 9) Nominet's Dynamic Updates [Jay Daley][15 min] X) I/O with other WGs [chairs][ 4 min] Y) A.O.B. [chairs][ 4 min] Z) Wrap-Up & Close [chairs][ 2 min] #############################################################################

1 0

.RU signed
by Max Tulyev 06 Apr '06

06 Apr '06

Hi! May be a bit offtopic here, but could be interesting ;) .RU now have a DNSSEC signed view as well as secure delegations. Details are on the http://www.dnssec.ru/ Now it is beta stage. Any comments/suggestion are wellcome. BIG THANKS to RIPE and especially RIPE NCC DNS/DNSSEC training courses that explained me DNSSEC infrastructure and give me an idea to make DNSSEC signed .RU domain! -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)

1 0

RIPE NCC DNSSEC Key Rollover
by Brett Carr 04 Apr '06

04 Apr '06

[Apologies for Duplicates] Dear Colleagues, The RIPE NCC changes the Key Signing Keys (KSKs) for its signed zones twice each year. We have today published new keys for all zones. Old keys will continue to function until the second stage of the rollover on 3 July 2006. We recommend that you reconfigure any resolvers to use the new keys before then. You can download them from: https://test-www.ripe.net/projects/disi//keys/ripe-ncc-dnssec-keys-new.txt The DNSSEC Key Maintenance Procedure is available at: https://test-www.ripe.net/rs/reverse/dnssec/key-maintenance-procedure.html If you have any questions about this, please send an e-mail to <ops(a)ripe.net>. Regards, Brett Carr RIPE NCC

1 1

DNSSEC: Signed zones list
by Max Tulyev 28 Feb '06

28 Feb '06

Hi! Where can I find the list of signed domains and their open keys to set up my DNS resolver? Which zones are signed now (exept RIPE's ones)? -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)

6 13

Name servers problems
by Jaap Akkerhuis 28 Feb '06

28 Feb '06

For those not on NANOG, on that list is quite some discussion going on about using (recursive) name servers for amplicication attacks. The discussion starts at http://www.merit.edu/mail.archives/nanog/threads.html#16000.o There is a special mailing list devoted on this problem by the isc: http://lists.oarci.net/mailman/listinfo/dns-operations, and this list is open to anyone. There is an US cert warning about this: http://www.us-cert.gov/reading_room/DNS-recursion121605.pdf. The upshot is: Close your open recursive nameservers. Other info: http://dns.measurement-factory.com/surveys/sum1.html and a plug for a secure template by the cymru guys: http://www.cymru.com/Documents/secure-bind-template.html Maybe all this is worth a slot at the coming dns-wg (or eof) meeting? jaap Acknowledgement: Information compiled from messages from Harvey Allen, Lucy Lynch, Rob Thomas and others.

3 2

DNS Misbehavior Doc
by David Malone 21 Feb '06

21 Feb '06

I've dusted off the Misbehavior of DNS document, cleaned it up a bit, added comments based on what was said on the mailing list when I last posted it (including some of the related issues mentioned). Do people think this is worth perusing as a RIPE document? Is the related issues section useful? Are the comments on testing useful? David. Misbehavior of DNS when faced with IPv6 or other New Query Types David Malone February 2005 Abstract This document is a short description of problems with certain DNS systems that have come to light with the deployment of IPv6 enabled software. 1. Introduction One of the services that DNS provides is a facility for mapping host names to IPv4 addresses. This is probably the most common used service that DNS provides, and is achieved requesting a record of type "A" for the host name. Records of type A can only store an IPv4 address, and so with the introduction of IPv6, a new record type, AAAA has been introduced. It is becoming increasingly common for software to first issue a request of type AAAA, and if no record of that type is found then to issue a request for a record of type A. A request for a record of type AAAA causes no problems for most DNS servers, however some DNS servers implementations have been found that have problems answering other queries. Some DNS implementations have problems with only new types, such as AAAA, and others have problems with any query not of type A. The end result of these issues is that connecting to a site using a problematic name server may be impossible, intermittent or significantly delayed. The technical details of these problems are explained in [RFC4074]. 2. Problem Extent In Q1 2004, a survey of nameservers for 24000 hostnames mentioned in web proxy logs found about 0.5--1% of name servers seem to have to have a problem of this nature. This corresponds to about 1.8% or URLS that are impacted by the problem. For more details of this survey see [IPJMISBEHAVE]. In terms of DNS server software, DNS load balancers seem to be commonly affected. This means that high-volume sites, such as ad servers, are often victims of this problem. Due to the embedding of ad-server images in web pages, the extent of the problem may be experienced by users of other web sites displaying these ads. 3. Testing New DNS Systems To prevent introducing more DNS servers with such issues, testing of new DNS equipment should include checking that the response for records is in accordance with the RFCs (in particular [RFC1035], [RFC3597] and [RFC4074] mentioned above). As DNS load balancing software has often fallen foul of these problems, particular care should be taken in testing and validating such systems. Simple testing can be conducted by making a query for a AAAA record using a tool such as dig. Supposing that the server has IP 192.0.2.1 and is to serve the domain example.com, queries such as the following should be made: dig AAAA exists.example.com @192.0.2.1 dig AAAA does-not-exist.example.com @192.0.2.1 dig AAAA www.subdomain.example.com @192.0.2.1 In each case the server should return the correct number of AAAA records (0 if there are none) and a status of NOERROR. Even if the server is only responsible for reverse zones, where queries for AAAA records are uncommon, such tests are still useful as reverse zones may still receive queries for other new record types. A simple web-based tool for testing is available at http://www.cnri.dit.ie/cgi-bin/check_aaaa.pl This tool can detect some of the most common problems given a domain name. 4. Addressing the Existing Problem The fact that problematic nameservers exist is in itself a problem. Where these issues cause direct inconvenience, the maintainers of the server and the maintainers of the DNS data should be notified to allow a normal service to be restored. However, often it is difficult for end users to identify the source of these problems, (for example, where an image embedded in a web page being served from a host with a problem hostname). It is also possible to automatically produce lists of names and nameservers that exhibit these problems. Clearly it is possible to automatically mail hostmaters or to publish "hall of shame" lists based on such data. It is unclear if such actions would achieve any useful effect, as service maintainers are usually primarily concerned about complaints directly from paying users! The action required to restore normal service may just require a simple software upgrade if the DNS Server vendor has already addressed these issues. A DNS server vendor should be able to address the issues using the RFCs referenced in this document. 5. Related Issues There are a number of other IPv6 related DNS issues that warrant mention. 5.1 A6 Records Initially, IPv6 addresses were to be determined in the DNS using A6 records, rather than AAAA records. Name servers that respond incorrectly to AAAA requests are also likely to respond incorrectly to A6 records. A6 queires are now considered experimental. 5.2 ip6.int vs. ip6.arpa Originally, two schemes were proposed for IPv6 reverse lookups. One used the ip6.int domain and the "nibble" format. The other used the ip6.arpa domain and the "bitstring" format. The system that has now been settled on uses the ip6.arpa domain and the nibble format. While some use of the ip6.int domain continues, it has been deprecated by [RFC4159]. 5.3 Resolver Issues There can also be issues with DNS resolvers. Some resolvers may not react as expected when asked to act on unusual addresses (such as IPv6 mapped addresses). Other resolvers have had problems if a host both IPv4 and IPv6 addresses. Still others have had problems if hosts have only IPv6 addresses. Some of these issues can be worked around by the application developer, however many vendors now have software updates to address these issues. 6. Acknowledgments This work is a product of the RIPE DNS Working Group. 7. References [RFC1035] P. Mockapetris, "Domain Names - Implementation and Specification", RFC 1035, STD 13, November 1987 [RCF3597] A. Gustafsson, "Handling of Unknown DNS Resource Record (RR) Types", RFC 3597, September 2003. [RFC4074] Y. Morishita and T. Jinmei, "Common Misbehavior Against DNS Queries for IPv6 Addresses", RFC 4074, May 2005. [RFC4159] G. Huston, "Deprecation of "ip6.int"", RFC 4159, August 2005. [IPJMISBEHAVE] D. Malone, 'Misbehaving Name Servers and What They're Missing', The Internet Protocol Journal - Volume 8, Number 1, March 2005.

4 5