by RSS Dehui Yin  |  Jan 25, 2017  |  Filed in: Security Research

The latest patch for BIND from the Internet Systems Consortium (ISC) fixes a NESC record-related bug. Remote BIND recursive servers may crash when attempting to handle the specifically-crafted query response with NESC record sent by attackers, thereby causing a denial of service (DoS).

This potential DoS vulnerability is caused by a RUNTIME CHECK error in Resolver.c when caching the DNS response with NSEC Record. In this post we will examine the BIND source codes and expose the root cause of this vulnerability.

The NSEC record (record type 47) is provided by the Domain Name System Security Extensions (DNSSEC) to handle non-existent names in DNS. It links all the names in the zone and lists all the record types related to each name. As a part of DNSSSEC validation, resolvers use the information offered by NESC records to verify the non-existence of the DNS query name or record type in the zone.

The RDATA field of NSEC record has the following format:

                         1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    /                      Next Domain Name                         /
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    /                   List of Type Bit Map(s)                     /
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 

The "Next Domain Name" indicates the next name in the zone and the "List of Type Bit Map(s)" lists all the record types related to this name in the zone.

The NSEC record is always included in the AUTHORITY section of DNS response. If DNSSEC is enabled, BIND named extracts the information of the NSEC record for further DNSSEC validation when handling and caching the record in the ANSWER section of DNS response. After extracting the information, BIND named associates it with the record in the ANSWER section of DNS response. If the association is unsuccessful, a RUNTIME CHECK error in function "cache_name()" of Resolver.c is triggered and makes BIND named exit.

The following code snippet was taken from BIND version 9.10.4-P4. Comments added by me have been highlighted.

resolver.c:

//cache the record name in the ANSWER section of DNS response

5246     static inline isc_result_t

5247     cache_name(fetchctx_t *fctx, dns_name_t *name, dns_adbaddrinfo_t *addrinfo,

5248                   isc_stdtime_t now)

5249     {

....

5603                                        if (ANSWER(rdataset) &&

5604                                           rdataset->type != dns_rdatatype_rrsig) {

5605                                                    isc_result_t tresult;

5606                                                    dns_name_t *noqname = NULL;

                                                                  //extract the information of the NSEC record and store it in "noqname".

5607                                                    tresult = findnoqname(fctx, name,

5608                                                                                  rdataset->type, &noqname);

5609                                                    if (tresult == ISC_R_SUCCESS &&

5610                                                        noqname != NULL) {

                                                                         //associate the information extracted from NSEC record with the current record received from the ANSWER section. "rdataset" points to this record.

5611                                                                tresult = dns_rdataset_addnoqname(

5612                                                                                            rdataset, noqname);

                                                                        //do the RUNTIME CHECK, if function "dns_rdataset_addnoqname()" doesn't return "ISC_R_SUCCESS", RUNTIME_CHECK fails and makes BIND named exit.

5613                                                                RUNTIME_CHECK(tresult == ISC_R_SUCCESS);

5614                                                    }

5615                                        }

 

rdataset.c:

637    isc_result_t

638    dns_rdataset_addnoqname(dns_rdataset_t *rdataset, dns_name_t *name) {

639   

640      REQUIRE(DNS_RDATASET_VALID(rdataset));

641      REQUIRE(rdataset->methods != NULL);

642      if (rdataset->methods->addnoqname == NULL)

643                  return (ISC_R_NOTIMPLEMENTED);

             //call the callback function. In this case, it is "isc__rdatalist_addnoquname()".

644      return((rdataset->methods->addnoqname)(rdataset, name));

645    }

 

rdatalist.c:

191    isc__rdatalist_addnoqname(dns_rdataset_t *rdataset, dns_name_t *name) {

192      dns_rdataset_t *neg = NULL;

193      dns_rdataset_t *negsig = NULL;

194      dns_rdataset_t *rdset;

195      dns_ttl_t ttl;

196   

197      REQUIRE(rdataset != NULL);

198   

199      for (rdset = ISC_LIST_HEAD(name->list);

200           rdset != NULL;

201           rdset = ISC_LIST_NEXT(rdset, link))

202      {

                         //if the "class" field of the NSEC record doesn't match the "class" field of the record needed to be associated, loop continues and "neg" cannot be set value. 

203                  if (rdset->rdclass != rdataset->rdclass)

204                              continue;

205                  if (rdset->type == dns_rdatatype_nsec ||

206                      rdset->type == dns_rdatatype_nsec3)

207                              neg = rdset;

208      }

             //neg cannot be set value and is nul., ISC_R_NOTFOUND is returned, which will trigger the RUNTIME_CHECK error.

209      if (neg == NULL)

210                  return (ISC_R_NOTFOUND);

Following is the image showing the abortion of the affected DNS server:

Please note that authentication is NOT required to exploit this vulnerability.

Fortinet released IPS signature ISC.BIND.NSEC.Record.Handling.DoS to address this vulnerability.

Sign up for weekly Fortinet FortiGuard Labs Threat Intelligence Briefs and stay on top of the newest emerging threats.

by RSS Dehui Yin  |  Jan 25, 2017  |  Filed in: Security Research
Tags: