OUSPG

[This page is CSS2 enabled. Your browser might not fully support it]

PROTOS Test-Suite: c09-dns

$RCSfile: index.html,v $ $Revision: 1.31 $ $Date: 2006/05/10 07:15:08 $

Status: not released

ABSTRACT

The Domain Name System (DNS) is the primary naming system used on the Internet. It employs a custom protocol, which is also called DNS. DNS systems use this protocol use to transact their business. DNS is a distributed hierarchical database, that is used among other things to map domain names to Internet addresses, map Internet addresses to domain names, direct mail delivery. A set of DNS messages was chosen as the subject protocol for vulnerability assessment through syntax testing and test-suite creation. A survey of the related standards was made. Test-material was prepared and tests were carried out against a sample set of existing implementations. Some of the implementations available for evaluation failed to perform in a robust manner under the test. Some failures had information security implications, and should be considered as vulnerabilities. Therefore, this robustness test-material should be adopted for the evaluation and development of DNS implementations.

Table of Contents

• ABSTRACT
• Table of Contents
• Introduction
• Test-Suite Design
  • Standard Survey
  • Subject Survey
  • Injection Vector Survey
  • Specifications Design
  • Design of Exceptional Elements
  • Design of Test-Material
• Implementation
  • Injection
  • Instrumentation
  • Test-Runs
  • Results
  • Verification via Exploits
• Test-Material Package
  • Package Information
  • License and Copyright
  • Prerequisites
  • Usage
    • The query material
    • The response material
    • The zone transfer material
    • The TCP-UDP proxy
    • A proxy for testing non-standard servers
  • Download
    • Release 1
  • Common test tool error messages
• Conclusions
  • Acknowledgements
• Vulnerability Management
  • Prior Public Vulnerabilities
  • The Vulnerability Process
  • Advisories and Vendor Statements
• References
• Appendix A: Related Test-Suites

Introduction

This test-suite is a byproduct of the "PROTOS - Security Testing of Protocol Implementations" project. [1] This test-suite covers a limited set of information security and robustness related implementation errors within the chosen focus area. Important: Background, goals, limitations, terminology and licensing for this test-suite release are explained in the "Test-suite releases in Theory and Practice" document. This test-suite covers a limited set of information security and robustness related implementation errors for a subset of the chosen protocol.

The purpose of this test-suite is to evaluate implementation level security and robustness of Domain Name System (DNS) implementations. The factors behind choosing DNS included:

• DNS is a fundamental infrastructure service of the Internet, and most Internet applications are dependent on it.
• DNS implementations are commonly ubiquitous, present in servers, end-user equipment such as personal computers and mobile phones, and in routers and firewalls. DNS may thus 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.

This test material is scoped to include basic queries, dynamic updates, basic responses, and zone transfers. Specifications design broadly describe which resource records we cover. This test material is not specifically designed to uncover cache poisoning or address spoofing vulnerabilities. Rationale for this scoping was:

• Desire to apply test material to stub resolvers, caching servers, authoritative servers and secondary servers.
• Zone transfers were speculated to exercise different code paths in servers than basic responses. The case of dynamic updates versus normal queries is thought similar.
• ...

The test material covers the following scenarios employing the DNS protocol:

1. test material -> [queries, dynamic DNS updates] -> DNS server
2. test material -> [query replies] -> DNS server
3. test material -> [query replies] -> DNS stub resolver (client)
4. test material -> [zone transfers] -> secondary DNS server

Three test material packages were generated for these scenarios. The query material covers scenario 1, the response material covers 2-3 and the zone transfer material is responsible for test scenario 4.

Test-Suite Design

Standard Survey

The available standards were studied and analysed. The relevant specifications are listed below.

• RFC 1035 - DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION[2]
• RFC 2929 - Domain Name System (DNS) IANA Considerations [3]
• RFC 2136 - Dynamic Updates in the Domain Name System (DNS UPDATE) [4]
• RFC 2671 - Extension Mechanisms for DNS (EDNS0) [5]
• RFC 3007 - Secure Domain Name System (DNS) Dynamic Update [6]
• RFC 2845 - Secret Key Transaction Authentication for DNS (TSIG)[7]
• RFC 2065 - Secret Key Transaction Authentication for DNS (TSIG)[8]
• RFC 2874 - DNS Extensions to Support IPv6 Address Aggregation and Renumbering[9]
• RFC 2535 - Domain Name System Security Extensions[10]
• RFC 2931 - DNS Request and Transaction Signatures ( SIG(0)s )[11]

Subject Survey

A survey of available implementations is conducted. This should include a diverse selection of implementations in order to gain better insight into the applications implementing the protocol and to give a hint on the impact of potential vulnerabilities. A subset of the implementations is chosen to be tested during the test-suite creation and prerelease phases.

Additional lists of vendors, specific implementations and related information may be found from the following resources:

• DNS Resources Directory [12]
• fpdns - Fingerprinting DNS servers [13]

A body of implementations was chosen as a sample set to be tested during the test-suite creation and pre-release phases. Most likely reasons for omission of a specific product from the sample set include:

• no evaluation copy of the product was available
• a restrictive licence prohibited evaluation
• we were not aware of the product

Injection Vector Survey

The methods of delivering the test cases to the implementations under test are identified and analysed in the injection vector survey. Often there are various injection methods which cannot all be covered in the test-suite. Lower-priority vectors that are not available in all implementations might be missed by the survey.

This test suite does not support the injection of Multicast DNS packets. Multicast DNS was also not specifically not considered during test design.

Injection using TCP was selected for the test set. Queries are usually performed via UDP, and some implementations send UDP replies to TCP requests. A TCP-UDP proxy was written to enable communication with these subjects.

*message sequence for scenario 1

           query
test tool   --->  DNS server [test subject]


*message sequence for scenario 2

              query                           rec. query
DNS resolver   --->  DNS server [test subject]   --->   test tool
                                 ^                              |
                                 |    recursion query reply     |
                                  ------------------------------


*message sequence for scenario 3

                             query
DNS resolver [test subject]   --->  test tool
             ^                           |
             |          reply            |
              ---------------------------


*message sequence for scenario 4 consists of three message exchanges

First message exchange

              notify
test tool      --->     DNS server [test subject]
        ^                   |
        |  notify response  |
         -------------------


Second message exchange

                            SOA                       
                           query                      
DNS server [test subject]   --->  test tool         
           ^                          |           
           |       SOA response       |           
            --------------------------            


Third message exchange

         zone transfer
test tool    --->     DNS server [test subject]


The exceptional elements are delivered in the third exchange

Specifications Design

Protocol data unit specifications are used as a basis for generating the test-cases. The starting point for the design of the test-suite is to acquire or create a machine-readable representation of the protocol specification. The test-tool then utilises a custom dialect of BNF (Backus-Naur Form). BNF is capable of describing the context-free syntax of a specification, but is often insufficient for automated test-case generation. The specification is completed by rules which maintain semantic validity and provide communication channels necessary to simulate the protocol.

Most DNS data is conveyed via the use of structures called resource records. Thus much of the testing effort is centred around them. All resource record types are coarsely tested, but the structure of the following types are given more attention.

• HINFO: Host information
• MINFO: Mailbox or mailing list information
• MX: Mail exchanger
• NULL: Null record
• SOA: Start of authority marking the start of a zone
• TXT: Text string
• NXT: Next domain
• WKS: Well-known service, information about services at a host
• A6: IPv6 addresses
• OPT: DNS extension EDNS0
• KEY: DNSSEC public key
• TSIG: Transaction signature
• SIG: Public key signature

Design of Exceptional Elements

An exceptional element is a piece of data designed to provoke undesired behaviour of the test subject. A single test-case contains one or a few exceptional elements. An exceptional element can violate the protocol specification, although it often can be considered legal or in the hazy region between legal and illegal constructs. An exceptional element is an input that might not have been considered properly when implementing the software.

The following table lists the categories of the exceptional elements designed for the test-material:

Design of Test-Material

The test-material consists of test-cases simulating hostile input to the implementation under test. A test-case contains one or more exceptional elements, other elements being in their default state as exhibited by test case #1, i.e. the default case. Cases are arranged into test-groups, each covering a certain part of PDUs or containing similar anomalies. Details for the test messages are presented in the table below.

Legend:

• "Name" column represents the tag-names of the test-groups. Tags reflect the field and element names in the protocol specification. Tags can be used to follow which parts of the PDUs are being tested.
• "Exceptional Elements" column describes which exceptional element categories are integrated in the test-group.
• "Test Cases", "First Index" and "Last Index" columns describe the number of cases and the first and last test-case index in the test-group.

Implementation

Test-runs were conducted against the chosen sample of implementations. Specifications, exceptional elements, semantic rules, injectors and instrumentation were integrated as a test-tool configuration to enable automatic execution of the tests.

Injection

The test-tool provides communication rules for test-case injection, using a TCP server and client sockets. A TCP-UDP proxy program is provided for handling UDP messages, as required by most scenarios.

To test a DNS resolver implementation using the response test material, the resolver implementation should be configured to send DNS queries to the host running the response test tool.

To test a DNS server implementation using the response test material, the DNS server should be configured to forward all queries to the host running the response test tool. Repeated DNS A queries for unique names should be addressed to the tested DNS server. It is important for the queried domain names to be unique to prevent the tested DNS server from caching the answers. The DNS server should then forward queries to the response test tool, which will reply with response test cases that will be processed by the DNS server before being forwarded to the originator of the query.

To test a DNS server implementation using the query test material, the DNS server should be configured to answer queries from the host running the test tool. The query test tool will then send successive DNS queries containing test cases to the tested DNS server.

To test a DNS server using the zone transfer test material, the tested implementation should be configured to act as a slave server for the zone "protos.invalid.", and the address of the host running the zone transfer test tool should be configured as a master of that zone. The tested DNS server is sent DNS NOTIFY messages, and it should connect back to the test tool to receive zone transfer test cases after each respective NOTIFY message.

Instrumentation

The implementation under test is monitored for undesired behaviour that could have security implications. Instrumentation methods can roughly be divided to two categories.

Out-of-Band Instrumentation on the target platform includes debuggers, resource monitoring or custom made tools used to extract information from the implementation under test. Unfortunately, the modern trend of abusing the try-catch -type of constructs easily masks the exceptions generated by stack and memory corruption. Catching these hidden exceptions relies on the debugging skills of the developers themselves. Out-of-Band Instrumentation is often the preferred form of instrumentation.

In In-Band Instrumentation the implementation is monitored via the injection vector, ie. the same interface used to deliver the test-cases. While not necessarily checked for protocol conformance, absent or malformed responses can often reveal anomalous conditions such as denial of service. Also, the ability to accept subsequent test-cases indicates how they affect the performance of the target implementation. Especially with embedded devices, this form of instrumentation may be the only option easily available.

A valid case in-band instrumentation will be bundled with the test-material.

Test-Runs

Results

Results from the test-runs are summarised herein. Tables below represent the observations from feeding the test-material against the chosen subject software. Product names of the actual subjects are omitted to protect the innocent. Results are presented in a tabular form with test-cases divided into test-groups based on the exceptional element types utilised and PDU fields under examination.

Each failed test-case represents at minimum a denial of service type chance of exploiting the found vulnerability. In most cases, they represent memory corruption, stack corruption or other fatal error conditions. Some of these may lead exposure to typical buffer overflow exploits, allowing arbitrary code to be run or the system to be modified.

The verdict failed is granted if any of the following criteria is met and a single test-case can be identified to be responsible:

• A device undergoes a fatal failure and stops functioning normally.
• A process or a device crashes or hangs and needs to be restarted manually.
• A process or a device crashes and restarts automatically.
• A process consumes CPU and/or memory resources for an exceptionally long or indefinite time thus causing at least a denial of service.

If no single test-case can be identified but similar effects are observed, the verdict is inconclusive.

Sometimes, a subject gets corrupted so badly or is fundamentally so unstable that there is no way to collect accurate test-results for the whole test-run. Untested regions are marked as unknown.

Otherwise, the verdict is passed.

Legend:

• nnn: Each different test-run (tr-nnn) represents a different tested implementation.
• X: Verdict is failed
• I: Verdict is inconclusive
• -: Verdict is passed
• ?: Verdict is unknown

Please note that if a subject fails in a format string (fmtstring) test-group, the failure may be caused by a buffer overflow condition with a very long format string as a trigger. Should an implementation have failed in a format string category, but not in previous overflow category, it is then likely to contain a format string type of vulnerability.

The results are further summarised in the table below.

Verification via Exploits

To support the vulnerability reporting process, typically one exploit per implementation is refined and included in the respective vulnerability report. The exploit is only intended for demonstration purposes and is harmless as it is. Simplest of them only executes some harmless commands in the target system, typically with the privileges of the vulnerable process. Some only provide a demonstration by causing a Denial of Service (DoS) against the software.

To support the vulnerability reports to the respective vendors, following exploits were developed:

• None as of 2006-05-10

Test-Material Package

Package Information

The test-material is distributed as a JAR package. The package comprises of the following elements:

• Test-cases located in testcases/ directory
• Codenomicon Toolkit Engine for feeding the test-cases against the system under test.
• LICENSE.TXT - License for the test-material package
• README.TXT - Very short instructions

License and Copyright

The license allows free use and redistribution of the test-material package. However, modifying the test-material package is not allowed without a permission. See the license file for more information.

We recommend some additional guidelines, although these do not restrict the test-material licence. These guidelines can be found from the "Test-suite releases in Theory and Practice" document.

Prerequisites

A prerequisite for using the test-material is a properly configured and started implementation, preferably not in an open network.

For the query test material, the tested implementation should be configured to receive and process DNS queries on TCP port 53.

For the response test material, the tested implementation should be configured send DNS queries to TCP port 53 or UDP port 53, and process the resulting DNS responses.

For the zone transfer test material, the tested implementation should be configured to receive DNS NOTIFY messages on TCP port 53, and it should connect back to the test tool to receive the zone transfer test case after each NOTIFY message.

In addition, Java is required to execute the test material packages, and Python is needed to run the supplied TCP-UDP proxy. The package has been tested on Java 2 Platform, Standard Edition (J2SE) version 1.4.2, and the proxy on Python version 2.3.4.

Usage

The test-material is used through a command line interface. The test-material is run with java, using the -jar switch.

The query material

The command java -jar c09-dns-query-r1.jar --help displays the built-in help for the available command line options:

--host host       Target hostname or IP (required)
--port port       Target port (53)
--timeout timeout Timeout (ms) to wait for reply (10000)
--index index     Test case index, e.g. 0,1-6,50-
--delay delay     Delay (ms) between test cases (1000)
--showsent        Show sent messages (off)
--showreceived    Show received messages (off)
--instrument      Use valid-case instrumentation (off)
--validcase case  Index to use in valid-case instrumentation (0)
--help            Show command line help

The minimal command line required to run all test-cases against a server at host 10.10.10.2 would then be java -jar c09-dns-query-r1.jar --host 10.10.10.2.

The response material

The command java -jar c09-dns-response-r1.jar --help displays the built-in help for the available command line options:

--sourceport port Source port (53)
--timeout timeout Timeout (ms) to wait for reply (10000)
--index index     Test case index, e.g. 0,1-6,50-
--delay delay     Delay (ms) between test cases (1000)
--showsent        Show sent messages (off)
--showreceived    Show received messages (off)
--instrument      Use valid-case instrumentation (off)
--validcase case  Index to use in valid-case instrumentation (0)
--help            Show command line help

The minimal command line required to run the test-set would then be java -jar c09-dns-response-r1.jar. The test-tool then functions as a server and can be queried for test-cases by a desired test subject. Note that running the test tool with the default port 53 requires administrative privileges on some systems.

Following is an example demonstrating test automation of the response material. The included shell script uses the ISC dig tool as the test subject, and sends the queries to the host supplied as its argument.

$ java --jar c09-dns-response-r1.jar &
[1] 13412
$ cat > query.sh
#!/bin/sh
set -x
n=`date +%s`
while true; do
    dig @$1 $n.protos.invalid +time=1
    n=`expr $n + 1`
done
$ chmod +x query.sh
$ ./query.sh localhost

Note that in most scenarios you need to employ the TCP-UDP proxy to successfully use the response material!

The zone transfer material

The command java -jar c09-dns-zonetransfer-r1.jar --help displays the built-in help for the available command line options:

--host host       Target hostname or IP (required)
--port port       Target port (53)
--sourceport port Source port (53)
--timeout timeout Timeout (ms) to wait for reply (10000)
--index index     Test case index, e.g. 0,1-6,50-
--delay delay     Delay (ms) between test cases (1000)
--showsent        Show sent messages (off)
--showreceived    Show received messages (off)
--instrument      Use valid-case instrumentation (off)
--validcase case  Index to use in valid-case instrumentation (0)
--help            Show command line help

The minimal command line required to run all test-cases against host 10.10.10.2 would then be java -jar c09-dns-zonetransfer-r1.jar --host 10.10.10.2. The test-tool then functions as an authoritative name server supplying zone information records to the test subject. Note that running the test tool with the default port 53 requires administrative privileges on some systems.

Note that in most scenarios you need to employ the TCP-UDP proxy to successfully use the zone transfer material!

The TCP-UDP proxy

The program is meant to accompany the PROTOS DNS test material. Run it on the same computer that the DNS jar is running on, and it will handle UDP-TCP translation of DNS messages so that the test tool can receive DNS messages sent over UDP. The command udpproxy.py --help displays the built-in help for the available command line options:

-h  --help               This text
-l  --listenport NNN     UDP port to listen on
-e  --testtoolport NNN   TCP port used by the test tool on this computer
-a  --targetport  NNN    TCP port of target, for TCP replies
-d  --duptimeout         Discard duplicate packets received within 1 second
-x  --hexdumps           Display hex dumps of proxied traffic
                         (requires the "xxd" program in path)

All ports default to 53 (standard DNS port), and the default will work unless you have configured the test tool or test subject to use nonstandard port(s). Note that running udpproxy with the default port 53 requires administrative privileges on some systems.

Usage examples of udpproxy with the test material:

* Testing resolvers:

Execute the following commands on the test server machine:

java -jar c09-dns-response-r1.jar 2>&1 > testtool.out
updproxy.py --duptimeout

Execute a command loop on the test client machine:

(while sleep 1; do testsubject 2>&1; done) > testsubject.out


If the test subject uses TCP in queries, the proxy is not needed and
the packet flow during testing is simple:

                  2. TCP
test tool -------------------------> test subject
    ^                                    |
    |             1. TCP                 |
     ------------------------------------

If, on the other hand, the test subject uses UDP, using the proxy is
essential and results in the following packet flow:

test tool	                     test subject
 |  ^                                    |  ^  ^
 |  |   2. TCP               1. UDP      |  |  |
 |   ----------udpproxy <----------------   |  |
 |      3. TCP               4. TCP         |  |
  ------------>         --------------------   |
                             5. UDP            |
                        -----------------------


< --------------------- > < ------------------ >
       test server              test client

The udpproxy first tries to communicate to the test subject via TCP to
gain better packet tracking. It uses UDP as the fallback communication
method if TCP fails.

* Testing servers:

The c09-dns-query-r1.jar should not need the proxy at all, thus the
following example concerns only the zone transfer material.

Execute the following commands on the test server machine:

java -jar c09-dns-zonetransfer-r1.jar 2>&1 > testtool.out
updproxy.py

Run the test subject on the test client machine.

The packet flow during testing can be as follows:

                  7. TCP
          <------------------------------
                  1. TCP                 |
test tool -------------------------> test subject
 |  ^                                    |  ^  ^
 |  |   3. TCP               2. UDP      |  |  |
 |   ----------udpproxy <----------------   |  |
 |      4. TCP               5. TCP         |  |
  ------------>         --------------------   |
                             6. UDP            |
                        -----------------------

< --------------------- > < ------------------ >
       test server              test client

Again, the udpproxy first tries to communicate to the test subject via
TCP. The subject can reply either via TCP or UDP, and if the reply
comes via UDP it is handled by the proxy.

A proxy for testing non-standard servers

During preliminary testing, the NISCC Vulteam found various DNS servers that only listen for incoming UDP connections, in violation of RFC 1035. For testing these kinds of non-standard servers, the team wrote a proxy program, which accompanies the PROTOS DNS test material. The command tcpproxy.py --help displays the built-in help for the available command line options:

-h  --help                 Show this information
-l  --listenport <port%gt;    TCP port to listen on [5353]
-t  --targetport <port>    UDP port of target [53]
-a  --targetaddress <ip>   IP address of target [127.0.0.1]

Run tcpproxy on the same computer that hosts the non-standard server, and it will proxy the TCP messages sent by the DNS jar (to listenport) to the server via UDP (to targetport).

Download

Use of latest release (highest number) is recommended. Older releases are provided for completeness and reproduction.

Release 1

• c09-dns-query-r1.jar [PGP signature]
• c09-dns-response-r1.jar [PGP signature]
• c09-dns-zonetransfer-r1.jar [PGP signature]
• udpproxy.py [PGP signature]
• tcpproxy.py [PGP signature]

Common test tool error messages

The error messages might be due to peculiarities or misconfigurations of a certain subject, possible flaws in the subject or errors in the test-case.

Conclusions

Although this test-suite only deals with a subset of the DNS protocol, many of the implementations available for evaluation failed to perform in a robust manner under the test. Some failures had information security implications, and should be considered as vulnerabilities. Therefore, this robustness test-material should be adopted for the evaluation and development of DNS implementations.

Acknowledgements

We wish to express our gratitude to individual vendors who worked with us to protect their customers. Last, but not least, we are grateful to NISCC for their patient help, advice and active role during the vulnerability process.

Vulnerability Management

Prior Public Vulnerabilities

The most common sources for vulnerability information and exploits were covered and cross checked for potential and already known vulnerabilities in the implementations of the chosen protocol. Typical sources for finding out about existing vulnerabilities are databases and mailing-lists. Search-engines may also reveal information on past vulnerabilities.

There is a plethora of prior DNS vulnerabilities. Some are referenced below.

• "Multiple Vendor DNS Message Decompression Remote Denial of Service Vulnerability" [14]
• "Squid Proxy DNS Name Resolver Remote Denial Of Service Vulnerability" [15]
• "Cisco CNS Network Registrar DNS and DHCP Server Remote Denial of Service Vulnerabilities" [16]
• "Multiple Vendor DNS Response Flooding Denial Of Service Vulnerability" [17]
• "Sun Solaris in.named Remote Denial of Service Vulnerability" [18]
• "Symantec Client Firewall DNS Response Buffer Overflow Vulnerability" [19]
• "Microsoft ISA Server DNS Intrusion Filter Denial of Service Vulnerability" [20]
• "Smart IRC Daemon Remote Client DNS Buffer Overflow Vulnerability" [21]
• "Posadis DNS Request Question Section Denial Of Service Vulnerability" [22]
• "Hypermail CGI Mail Reverse DNS Lookup Buffer Overflow Vulnerability" [23]
• "Middleman net_dns() Frame Pointer Overwrite Vulnerability" [24]
• "PADL Software nss_ldap DNS Buffer Overflow Vulnerability" [25]
• "Sendmail DNS Map TXT Record Buffer Overflow Vulnerability" [26]
• "Multiple Vendor libc DNS Resolver Buffer Overflow Vulnerability" [27]
• "Ethereal DNS Dissector Infinite Loop Denial of Service Vulnerability" [28]
• "Bradford Barrett Webalizer Reverse DNS Buffer Overflow Vulnerability" [29]
• "Posadis DNS Server Logging Format String Vulnerability" [30]
• "Squid Compressed DNS Buffer Overflow Vulnerability" [31]
• "Apple MacOS 9 Classic Reverse DNS Lookup DoS Vulnerability" [32]
• "DNRD DNS Request/Reply Denial Of Service Vulnerability" [33]
• "Avaya Argent Office Malformed DNS Packet Denial of Service Vulnerability" [34]
• "Multiple IRCd DNS Denial of Service Vulnerability" [35]
• "BitchX DNS Buffer Overflow Vulnerability" [36]
• "AntiSniff DNS Overflow Vulnerability" [37]
• "Microsoft Windows 2000 DNS Memory Leak Vulnerability" [38]
• "Multiple Sniffer Vendor DNS Decode Vulnerability" [39]
• "Windows NT DNS Resolution Remote Buffer Overflow Vulnerability" [40]

ISC Bind, being the original and oldest DNS implementation, has a long history of vulnerabilities [41]. The Common Vulnerabilities and Exposures project has an exhaustive list on DNS vulnerabilities [42].

The Vulnerability Process

During the prerelease phase all verified vulnerabilities were reported to the respective vendors. The vulnerability reports were tracked by NISCC in the role of independent coordinator and advisor. An attempt was made to seek a channel to distribute the test material to vendors whose products we were not able to obtain for testing.

Advisories and Vendor Statements

Vendor statements or security advisories issued in order to address the vulnerabilities uncovered by this test-suite are collected. Advisories that we are aware of are listed here-in:

• NISCC advisory

References

[1]

"PROTOS - Security Testing of Protocol Implementations". University of Oulu. http://www.ee.oulu.fi/research/ouspg/protos.

[2]

P. Mockapetris. (1987). "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION". IETF. http://www.ietf.org/rfc/rfc1035.txt.

[3]

D. Eastlake 3rd, E. Brunner-Williams, B. Manning. (2000). "Domain Name System (DNS) IANA Considerations". IETF. http://www.ietf.org/rfc/rfc2929.txt.

[4]

P. Vixie, S. Thomson, Y. Rekhter, J. Bound. (2000). "Dynamic Updates in the Domain Name System (DNS UPDATE)". IETF. http://www.ietf.org/rfc/rfc2136.txt.

[5]

P. Vixie. (1999). "Extension Mechanisms for DNS (EDNS0)". IETF. http://www.ietf.org/rfc/rfc2671.txt.

[6]

B. Wellington. (2000). "Secure Domain Name System (DNS) Dynamic Update". IETF. http://www.ietf.org/rfc/rfc3007.txt.

[7]

P. Vixie, O. Gudmundsson, D. Eastlake 3rd, B. Wellington. (2000). "Secret Key Transaction Authentication for DNS (TSIG)". IETF. http://www.ietf.org/rfc/rfc2845.txt.

[8]

D. Eastlake 3rd, C. Kaufman. (1997). "Domain Name System Security Extensions". IETF. http://www.ietf.org/rfc/rfc2065.txt.

[9]

M. Crawford, C. Huitema. (2000). "DNS Extensions to Support IPv6 Address Aggregation and Renumbering". IETF. http://www.ietf.org/rfc/rfc2874.txt.

[10]

D. Eastlake. (1999). "Domain Name System Security Extensions". IETF. http://www.ietf.org/rfc/rfc2535.txt.

[11]

D. Eastlake. (2000). "DNS Request and Transaction Signatures ( SIG(0)s )". IETF. http://www.ietf.org/rfc/rfc2931.txt.

[12]

A. Salamon. (2005). "DNS Resources Directory". http://www.dns.net/dnsrd/.

[13]

R. Arends, J. Schlyter. (2004). "fpdns - Fingerprinting DNS servers". http://www.rfc.se/fpdns/.

[14]

Dr. Steve Beaty. (2005). "Multiple Vendor DNS Message Decompression Remote Denial of Service Vulnerability". Securityfocus. http://www.securityfocus.com/bid/13729.

[15]

Squid. (2005). "Squid Proxy DNS Name Resolver Remote Denial Of Service Vulnerability". Securityfocus. http://www.securityfocus.com/bid/12551.

[16]

Cisco. (2004). "Cisco CNS Network Registrar DNS and DHCP Server Remote Denial of Service Vulnerabilities". Securityfocus. http://www.securityfocus.com/bid/11793.

[17]

Roy Arends and Jakob Schlyter. (2004). "Multiple Vendor DNS Response Flooding Denial Of Service Vulnerability". Securityfocus. http://www.securityfocus.com/bid/11642.

[18]

Sun. (2004). "Sun Solaris in.named Remote Denial of Service Vulnerability". Securityfocus. http://www.securityfocus.com/bid/11118.

[19]

eEye. (2004). "Symantec Client Firewall DNS Response Buffer Overflow Vulnerability". Securityfocus. http://www.securityfocus.com/bid/10334.

[20]

Mike Fratto. (2003). "Microsoft ISA Server DNS Intrusion Filter Denial of Service Vulnerability". Securityfocus. http://www.securityfocus.com/bid/7145.

[21]

Knud Erik Højgaard.. (2003). "Smart IRC Daemon Remote Client DNS Buffer Overflow Vulnerability". Securityfocus. http://www.securityfocus.com/bid/6924.

[22]

Posadis. (2003). "Posadis DNS Request Question Section Denial Of Service Vulnerability". Securityfocus. http://www.securityfocus.com/bid/6799.

[23]

Ulf Harnhammar. (2003). "Hypermail CGI Mail Reverse DNS Lookup Buffer Overflow Vulnerability". Securityfocus. http://www.securityfocus.com/bid/6690.

[24]

qitest1@bespin.org. (2003). "Middleman net_dns() Frame Pointer Overwrite Vulnerability". Securityfocus. http://www.securityfocus.com/bid/6584.

[25]

PADL Software. (2002). "PADL Software nss_ldap DNS Buffer Overflow Vulnerability". Securityfocus. http://www.securityfocus.com/bid/6129.

[26]

Joost Pol and Anton Rang. (2002). "Sendmail DNS Map TXT Record Buffer Overflow Vulnerability". Securityfocus. http://www.securityfocus.com/bid/5122.

[27]

Joost Pol. (2002). "Multiple Vendor libc DNS Resolver Buffer Overflow Vulnerability". Securityfocus. http://www.securityfocus.com/bid/5100.

[28]

Ethereal. (2002). "Ethereal DNS Dissector Infinite Loop Denial of Service Vulnerability". Securityfocus. http://www.securityfocus.com/bid/4807.

[29]

spybreak@host.sk. (2002). "Bradford Barrett Webalizer Reverse DNS Buffer Overflow Vulnerability". Securityfocus. http://www.securityfocus.com/bid/4504.

[30]

kkr@dekode.org. (2002). "Posadis DNS Server Logging Format String Vulnerability". Securityfocus. http://www.securityfocus.com/bid/4378.

[31]

zen-parse@gmx.net. (2002). "Squid Compressed DNS Buffer Overflow Vulnerability". Securityfocus. http://www.securityfocus.com/bid/4363.

[32]

Jason Linhart. (2002). "Apple MacOS 9 Classic Reverse DNS Lookup DoS Vulnerability". Securityfocus. http://www.securityfocus.com/bid/4151.

[33]

Andrew Griffits. (2002). "DNRD DNS Request/Reply Denial Of Service Vulnerability". Securityfocus. http://www.securityfocus.com/bid/3928.

[34]

Jacek Lipkowski. (2001). "Avaya Argent Office Malformed DNS Packet Denial of Service Vulnerability". Securityfocus. http://www.securityfocus.com/bid/8976.

[35]

David Luyer. (2000). "Multiple IRCd DNS Denial of Service Vulnerability". Securityfocus. http://www.securityfocus.com/bid/2086.

[36]

nimrood@onebox.com. (2000). "BitchX DNS Buffer Overflow Vulnerability". Securityfocus. http://www.securityfocus.com/bid/2087.

[37]

Hugo Breton. (2000). "AntiSniff DNS Overflow Vulnerability". Securityfocus. http://www.securityfocus.com/bid/1207.

[38]

Microsoft. (2000). "Microsoft Windows 2000 DNS Memory Leak Vulnerability". Securityfocus. http://www.securityfocus.com/bid/2007.

[39]

scut@nb.in-berlin.de and Hugo Breton. (1999). "Multiple Sniffer Vendor DNS Decode Vulnerability". Securityfocus. http://www.securityfocus.com/bid/1165.

[40]

unknown. (1999). "Windows NT DNS Resolution Remote Buffer Overflow Vulnerability". Securityfocus. http://www.securityfocus.com/bid/6898.

[41]

ISC. (2005). "BIND Vulnerabilities". ISC. http://www.isc.org/index.pl?/sw/bind/bind-security.php.

[42]

ISC. (2005). "CVE database search results on DNS". ISC. http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=dns.

Appendix A: Related Test-Suites

A survey of other existing test-suites related to DNS was conducted.

http://www.codenomicon.com/products/internet/dns/

"Codenomicon DNS Test Tool helps proactively eliminate security flaws in DNS implementations."

http://wiki.ethereal.com/SampleCaptures#head-c9783b0549c8c653d43b4837d148167f805581a9

Packet capture files containing DNS messages with malformed compression.

[This page is CSS2 enabled. Your browser might not fully support it]