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:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / 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.