The Analysis of ISC BIND Response Authority Section RRSIG Missing DoS (CVE-2016-9444)
Credit to Author: | Date: Mon, 06 Feb 2017 09:46:31 -0800
Domain Name System Security Extensions (DNSSEC) secures the Domain Name System (DNS), right?
Yes, but that’s not the whole story. DNSSEC can also introduce troubles into your DNS server.
Recently, a BIND bug caused by a missing RRSIG record, which is a part of DNSSEC, was fixed by a patch from the Internet Systems Consortium (ISC). This bug affects all versions of BIND recursive servers, and can cause a denial of service (DoS.)
This potential DoS vulnerability is caused by a RUNTIME CHECK error in Resolver.c when handling the DNS query response AUTHORITY section without covering RRSIG. In this post we will examine the BIND source codes and expose the root cause of this vulnerability.
The RRSIG record (record type 46) holds a DNSSEC signature for records with the same name and type. DNS Resolvers use this cryptographic signature to verify that a zone has signed these records.
The RDATA field of RRSIG 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type Covered | Algorithm | Labels |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Original TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signature Expiration |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signature Inception |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Tag | /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Signer's Name /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ /
/ Signature /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The "Type Covered" field in the RDATA field above indicates the type of the record covered by the RRSIG record. It is important to know that there may be several records with the same name as the RRSIG record, which causes a problem for DNSSEC.
If DNSSEC is enabled, an RRSIG record should cover every record in the DNS response ANSWER section and the AUTHORITY section. However, for records with the same name, BIND named fails to check the match in the AUTHORITY section between the record and the covering RRSIG, which causes a RUNTIME CHECK error in resolver.c and forces named to 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 records from AUTHORITY section and store it in "noqname".
5607 tresult = findnoqname(fctx, name,
5608 rdataset->type, &noqname);
The malformed AUTHORITY section has the following form:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NESC3 record |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| covering RRSIG for NESC3 record |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NESC record without covering RRSIG |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The BIND named links all the records with the same name in a list and manipulates them by checking the list in a loop. In the example above, three records in the AUTHORITY section have the same name and will be linked in one list. This list is used as "nsec->list" and "name->list" in the following codes.
resolver.c:
5119 findnoqname(fetchctx_t *fctx, dns_name_t *name, dns_rdatatype_t type,
5120 dns_name_t **noqnamep)
5121 {
….
5183 section = DNS_SECTION_AUTHORITY;
//check the records in AUTHORITY section one by one in a loop
5184 for (result = dns_message_firstname(fctx->rmessage, section);
5185 result == ISC_R_SUCCESS;
5186 result = dns_message_nextname(fctx->rmessage, section)) {
5187 dns_name_t *nsec = NULL;
5188 dns_message_currentname(fctx->rmessage, section, &nsec);
5189 for (nrdataset = ISC_LIST_HEAD(nsec->list);
5190 nrdataset != NULL; nrdataset = next) {
….
5212 //parse the NSEC3 record at first and return successfully, "noqname" will be set the "name" of the NSEC3 record.
5213 if (nrdataset->type == dns_rdatatype_nsec3 &&
5214 NXND(dns_nsec3_noexistnodata(type, name, nsec,
5215 nrdataset, zonename,
5216 &exists, &data,
5217 &optout, &unknown,
5218 &setclosest,
5219 &setnearest,
5220 closest, nearest,
5221 fctx_log, fctx)))
5222 {
5223 if (!exists && setnearest) {
5224 noqname = nsec;
5225 found = dns_rdatatype_nsec3;
….
//parse the NSEC record
5201 if (nrdataset->type == dns_rdatatype_nsec &&
5202 NXND(dns_nsec_noexistnodata(type, name, nsec,
5203 nrdataset, &exists,
5204 &data, NULL, fctx_log,
5205 fctx)))
5206 {
//craft the NSEC record and make "exists" return "true", noqname will not change, it is still the "name" of the NSEC3 record.
5207 if (!exists) {
5208 noqname = nsec;
5209 found = dns_rdatatype_nsec;
….
resolver.c:
//return to "cache_name()" function
5609 if (tresult == ISC_R_SUCCESS &&
5610 noqname != NULL) {
//associate the NSEC3 record and the 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);
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:
190 isc_result_t
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 {
203 if (rdset->rdclass != rdataset->rdclass)
204 continue;
//because the NSEC3 record and the NSEC record have the same name, they are linked in one list, which is "name->list" here, but the NSEC record is after the NSEC3 record in the list. As a result, neg points to the NSEC record but not the NSEC3 record.
205 if (rdset->type == dns_rdatatype_nsec ||
206 rdset->type == dns_rdatatype_nsec3)
207 neg = rdset;
208 }
….
212 for (rdset = ISC_LIST_HEAD(name->list);
213 rdset != NULL;
214 rdset = ISC_LIST_NEXT(rdset, link))
215 {
//the NSEC record doesn't have a covering RRSIG, so nesig cannot be set value.
216 if (rdset->type == dns_rdatatype_rrsig &&
217 rdset->covers == neg->type)
218 negsig = rdset;
219 }
220
//negsig cannot be set value and is nul., ISC_R_NOTFOUND is returned, which triggers the RUNTIME_CHECK error.
221 if (negsig == NULL)
222 return (ISC_R_NOTFOUND)
The following image shows the abortion of the affected DNS server:
Please note that authentication is NOT required to exploit this vulnerability.
Remedey
Fortinet released IPS signature ISC.BIND.Response.Authority.Section.RRSIG.Missing.DoS to address this vulnerability.
https://blog.fortinet.com/feed