Another TKEY record-related bug in BIND has been fixed with a patch from the Internet Systems Consortium (ISC) that was released just after the New Year. This bug may take down BIND recursive servers by sending a simple query response with TKEY record, thereby causing a denial of service (DoS).
This potential DoS vulnerability is caused by an assertion failure in Resolver.c when caching the DNS response with TKEY Record. In this post we will analyze the BIND source codes and expose the root cause of this vulnerability.
The TKEY record (record type 249) is used to operate the secret keys information shared between DNS resolvers and servers. It is not supposed to be in the DNS ANY query response, which responds to the DNS query with Type ANY, nor stored or cached by DNS recursive servers. This bug is caused by a mismatch error when DNS recursive servers tryto cache the TKEY record in the DNS ANY query response.
The following code snippet was taken from BIND version 9.10.4-P4. Comments added by me have been highlighted.
Resolver.c:
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 {
...
//caching the TKEY Record in the DNS ANY query response
5620 result = dns_db_addrdataset(fctx->cache,
5621 node, NULL, now,
5622 rdataset,
5623 options,
5624 addedrdataset);
db.c:
749 isc_result_t
750 dns_db_addrdataset(dns_db_t *db, dns_dbnode_t *node, dns_dbversion_t *version,
751 isc_stdtime_t now, dns_rdataset_t *rdataset,
752 unsigned int options, dns_rdataset_t *addedrdataset)
753 {
754 /*
755 * Add 'rdataset' to 'node' in version 'version' of 'db'.
756 */
757
758 REQUIRE(DNS_DB_VALID(db));
759 REQUIRE(node != NULL);
760 REQUIRE(((db->attributes & DNS_DBATTR_CACHE) == 0 && version != NULL)||
761 ((db->attributes & DNS_DBATTR_CACHE) != 0 &&
762 version == NULL && (options & DNS_DBADD_MERGE) == 0));
763 REQUIRE((options & DNS_DBADD_EXACT) == 0 ||
764 (options & DNS_DBADD_MERGE) != 0);
765 REQUIRE(DNS_RDATASET_VALID(rdataset));
766 REQUIRE(dns_rdataset_isassociated(rdataset));
//db->rdclass comes from the ANY query which is "1", rdataset->rdclass is the "Class" property of TKEY record, which is "0xff", they doesn't match and assertion failure occurs.
767 REQUIRE(rdataset->rdclass == db->rdclass);
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.TKEY.Query.Reponse.Handling.DoS to address this vulnerability.
