BIND9 CVEs – Days from Report to Disclosure

Over the past five years, we have taken on average, 32 days to publicly disclose a BIND vulnerability, from the time we receive the first report.

 

Typical steps from report to disclosure include:

  • Set-up secure email link with reporter, request more details
  • Reproduce in house (this can take a while, particularly if the reporter can’t provide enough detail)
  • Team meeting to get a consensus on CVSS score
  • Allocate or request CVE#
  • Determine affected software versions
  • Develop, review and confirm a fix, commit to multiple branches
  • Draft and review CVE notice
  • Create and test patched versions
  • Notify support subscribers, root operators, OS packagers
  • Disclosure: Update ftp server, web server, email user mailing lists, vulnerability matrix, knowledge-base

An average of 32 days to get all of that done is reasonable.  Sometimes it takes longer, often because we are waiting to bundle several issues together, or avoid announcing right before a holiday.

What about the outliers buried in that average?

It is generally regarded as unresponsive to take more than 90 days from report of a vulnerability to publication.  We have exceeded that only once in this period, in 2012, when it took us 98 days to disclose CVE-2012-5688, ‘BIND 9 servers using DNS64 can be crashed by a crafted query.’  This report came from someone who was using heavily modified code, and it took a long time to find and identify the problem in our source.

At ISC, we take responsible vulnerability disclosure seriously.  We follow a consistent, documented process which includes prioritizing fixing and disclosing security vulnerabilities promptly.

 

References:

How to report a vulnerability

ISC’s vulnerability process

Public disclosure notices


Here is the source data for the chart above.

 

Report Date Description CVSS V2 Score CVE Number Public Release Date Elapsed Days
5/24/2012 High TCP query load can trigger a memory leak 5 CVE-2012-3868 7/24/2012 61
6/28/2012 Heavy DNSSEC validation load can cause a “Bad Cache” assertion failure 7.8 CVE-2012-3817 7/24/2012 26
6/1/2012 Handling of zero length rdata can cause named to terminate,unexpectedly 8.5 CVE-2012-1667 6/4/2012 3
7/25/2012 A specially crafted resource record could cause named to terminate 7.8 CVE-2012-4244 9/12/2012 49
8/28/2012 BIND 9 servers using DNS64 can be crashed by a crafted query 7.8 CVE-2012-5688 12/4/2012 98
9/21/2012 A specially crafted DNS data can cause a lockup in named 7.8 CVE-2012-5166 10/9/2012 18
12/12/2012 BIND unexpected closed when resolve RPZ and DNS64 7.8 CVE-2012-5869 1/24/2013 43
        Avg Elapsed Days 2012 43
           
2/21/2013 A maliciously crafted regular expression can cause memory exhaustion in named 7.8 CVE-2013-2266 3/26/2013 33
6/4/2013 A recursive resolver can be crashed by a query for a malformed zone 7.8 CVE-2013-3919 6/4/2013 0
7/15/2013 rdata Denial Of Service Vulnerability 7.8 CVE-2013-4854 7/26/2013 11
8/22/2013 A Winsock API bug can cause a side-effect with BIND ACLs 6.8 CVE-2013-6230 11/6/2013 76
12/18/2013 A crafted query against an NSEC3-signed zone can crash BIND 5.4 CVE-2014-0591 1/13/2014 26
        Avg Elapsed Days 2013 29
           
5/2/2014 prefetch crash. 7.8 CVE-2014-3214 5/8/2014 6
5/24/2014 EDNS options crash. 7.8 CVE-2014-3859 6/11/2014 18
10/17/2014 An infinite chain of delegations (in a maliciously crafted zone) can cause BIND to consume all resources while following the delegations. 7.8 CVE-2014-8500 12/8/2014 52
11/1/2014 Assertion failure when geolocation database not loaded 5.4 CVE-2014-8680 12/8/2014 37
        Avg Elapsed Days 2014 28
           
1/15/2015 Crash (assertion failed) upon attempting to retrieve trust anchor 5.4 CVE-2015-1349 2/18/2015 34
6/15/2015 Crash in name.c. 7.8 CVE-2015-4620 7/7/2015 22
7/13/2015 Failure to reset variable to NULL in tkey.c. 7.8 CVE-2015-5477 7/28/2015 15
8/1/2015 Assert in parsing of DNSSEC keys with malformed input. 7.8 CVE-2015-5722 9/2/2015 32
8/8/2015 Assertion failure parsing OPENPGPKEY wire data. 7.1 CVE-2015-5986 9/2/2015 25
10/19/2015 REQUIRE(rdataset->rdclass == db->rdclass) failed. 7.1 CVE-2015-8000 12/15/2015 57
12/1/2015 INSIST assertion failure in resolver.c:fctx_query(). 5.4 CVE-2015-8461 12/15/2015 14
12/29/2015 INSIST in apl_42.c when printing record. 6.8 CVE-2015-8704 1/19/2016 21
12/29/2015 REQUIRE when printing out OPT record. 5.4 CVE-2015-8705 1/19/2016 21
        Avg Elapsed Days 2015 27
           
1/22/2016 A REQUIRE assertion failure can be deliberately triggered in servers performing NXDOMAIN redirection. 5.4 CVE-2016-1284 2/3/2016 12
2/9/2016 REQUIRE assertion in named during rndc pre-authentication. 7.8 CVE-2016-1285 3/9/2016 29
2/19/2016 Crash with an INSIST when the response contains an RRSIG RR covering DNAME where the owner name of the RRSIG RR is not a subdomain of the query for any query (of any type). 7.8 CVE-2016-1286 3/9/2016 19
2/26/2016 named will crash with an INSIST when the response contains an OPT metarecord with multiple COOKIE options. 7.8 CVE-2016-2088 3/9/2016 12
6/21/2016 Potential DoS against lwresd via specially crafted query 5.4 CVE-2016-2775 7/18/2016 27
8/31/2016 An error in a buffer length check when rendering reply messages can cause an assertion failure in buffer.c when named is sent a specially constructed packet. 7.8 CVE-2016-2776 9/21/2016 21
10/1/2016 A specially crafted packet could crash older (unsupported) versions of BIND 7.8 CVE-2016-2848 10/20/2016 19
10/20/2016 Badly constructed DNAME zone data on authoritative server might cause a resolver to crash 7.5 CVE-2016-8864 11/1/2016 12
10/31/2016 A malformed response to an ANY query can cause an assertion failure during recursion 7.5 CVE-2016-9131 1/11/2017 72
11/2/2016 An error handling a query response containing inconsistent DNSSEC information could cause an assertion failure bind 7.5 CVE-2016-9147 1/11/2017 70
11/14/2016 An unusually-formed DS record response could cause an assertion failure 7.5 CVE-2016-9444 1/11/2017 58
12/7/2016 An error handling certain queries using the nxdomain-redirect feature could cause a REQUIRE assertion failure in db.c 7.5 CVE-2016-9778 1/11/2017 35
        Avg Elapsed Days 2016 32
           
1/17/2017 An unhandled interaction between RPZ and DNS64 can cause a segmentation fault when named attempts to get the record count of a disassociated record set. 7.5 CVE-2017-3135 2/8/2017 22
2/9/2017 DNS64 Wildcard Break DNSSEC 5.9 CVE-2017-3136 4/12/2017 62
2/21/2017 A response packet can cause a resolver to terminate when processing an answer containing a CNAME or DNAME 7.5 CVE-2017-3137 4/12/2017 50
03/20/17 named exits with a REQUIRE assertion failure if it receives a null command string on its control channel 6.5 CVE-2017-3138 4/12/2017 23
5/4/2017 RPZ looping FORMERR 3.7 CVE-2017-3140 6/14/2017 41
05/14/17 Windows Service path not quoted 7.2 CVE-2017-3141 6/14/2017 31
        Avg Elapsed Days 2017 38

 

 

This post was updated after initial publication, to correct an error in the publication date for CVE-2017-3136. Publication of CVE-2017-3136 was originally scheduled for 8 March, and was delayed when we received the two later vulnerability reports, and all 3 were subsequently released together on April 12, 2017.

Last modified: August 3, 2017 at 4:49 pm