Bug 1441133 (CVE-2017-3137)

Summary:	CVE-2017-3137 bind: Processing a response containing CNAME or DNAME with unusual order can crash resolver
Product:	[Other] Security Response	Reporter:	Adam Mariš <amaris>
Component:	vulnerability	Assignee:	Red Hat Product Security <security-response-team>
Status:	CLOSED ERRATA	QA Contact:	Petr Sklenar <psklenar>
Severity:	high	Docs Contact:
Priority:	high
Version:	unspecified	CC:	apmukher, dominik.mierzejewski, hagedorn, jaeshin, jiml, mlindner, pemensik, security-response-team, slawomir, slong, swsnyder, vanicekp, yozone
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	bind 9.9.9-P8, bind 9.10.4-P8, bind 9.11.0-P5	Doc Type:	If docs needed, set a value
Doc Text:	A denial of service flaw was found in the way BIND handled a query response containing CNAME or DNAME resource records in an unusual order. A remote attacker could use this flaw to make named exit unexpectedly with an assertion failure via a specially crafted DNS response.	Story Points:	---
Clone Of:		Environment:
Last Closed:	2019-06-08 03:10:11 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	1441611, 1441612, 1441912, 1441913, 1442957, 1442959, 1455274, 1455275, 1455276, 1455277, 1455278, 1455280
Bug Blocks:	1441140

Description Adam Mariš 2017-04-11 09:45:09 UTC

Mistaken assumptions about the ordering of records in the answer section of a response containing CNAME or DNAME resource records could lead to a situation in which named would exit with an assertion failure when processing a response in which records occurred in an unusual order.

A server which is performing recursion can be forced to exit with an assertion failure if it can be caused to receive a response containing CNAME or DNAME resource records with certain ordering.  An attacker can cause a denial of service by exploiting this condition.  Recursive resolvers are at highest risk but authoritative servers are theoretically vulnerable if they perform recursion.

External References:

https://kb.isc.org/article/AA-01466

Comment 1 Adam Mariš 2017-04-11 09:45:16 UTC

Acknowledgments:

Name: ISC

Comment 6 Dhiru Kholia 2017-04-13 05:33:23 UTC

Created bind tracking bugs for this issue:

Affects: fedora-all [bug 1441912]

Comment 7 Dhiru Kholia 2017-04-13 05:33:30 UTC

Created bind99 tracking bugs for this issue:

Affects: fedora-all [bug 1441913]

Comment 12 errata-xmlrpc 2017-04-19 06:28:56 UTC

This issue has been addressed in the following products:

  Red Hat Enterprise Linux 7

Via RHSA-2017:1095 https://access.redhat.com/errata/RHSA-2017:1095

Comment 13 errata-xmlrpc 2017-04-20 12:54:36 UTC

This issue has been addressed in the following products:

  Red Hat Enterprise Linux 6

Via RHSA-2017:1105 https://access.redhat.com/errata/RHSA-2017:1105

Comment 17 Steve Snyder 2017-04-26 11:45:45 UTC

This fix does not seem to addressed the problem, at least not on RHEL6.  Or possibly the fix replaced one fatal bug with another.

Before applying update:

20-Apr-2017 09:16:36.407 general: resolver.c:4286: INSIST(fctx->type == ((dns_rdatatype_t)dns_rdatatype_any) || fctx->type == ((dns_rdatatype_t)dns_rdatatype_rrsig) || fctx->type == ((dns_rdatatype_t)dns_rdatatype_sig)) failed
20-Apr-2017 09:16:36.408 general: exiting (due to assertion failure)

After update:

25-Apr-2017 12:51:18.490 general: validator.c:1861: INSIST(rdataset->type == ((dns_rdatatype_t)dns_rdatatype_dnskey)) failed
25-Apr-2017 12:51:18.490 general: exiting (due to assertion failure)

Comment 18 Steve Snyder 2017-04-27 10:46:31 UTC

I've been contacted by Red Hat's Product Security Team asking for details on how to reproduce this.  I should have addressed this in my comment #17 above.

I don't know how to reproduce it.  I administer several DNS servers that are open to the public, all running on CentOS v6.9/x86_64.  After the recent update ( bind-9.8.2-0.62.rc1.el6_9.1.src.rpm ) was released I updated all my servers as soon as possible.

Since that time I've been getting the assertion failure in validator.c shown above.  I could post my named.conf if that would be helpful, but I can't provide code that would trigger the assertion.

Please let me know if I can provide further information.

Comment 20 Jim Lohiser 2017-05-01 13:18:44 UTC

We were also seeing the crash with validator.c. I have rolled back from 9.8.2-0.62.rc1.el6_9.1 to 9.8.2-0.62.rc1.el6.x86_64 and I now stable again.

Comment 22 Steve Snyder 2017-05-03 11:32:59 UTC

(In reply to Jim Lohiser from comment #20)
> We were also seeing the crash with validator.c. I have rolled back from
> 9.8.2-0.62.rc1.el6_9.1 to 9.8.2-0.62.rc1.el6.x86_64 and I now stable again.

Do you have "dnssec-validation auto" in your configuration?

I am advised by Red Hat to change this to "no" to prevent the assertion until they can get a fix released.

Comment 26 Sebastian Hagedorn 2017-05-30 17:01:47 UTC

(In reply to Steve Snyder from comment #22)
> (In reply to Jim Lohiser from comment #20)
> > We were also seeing the crash with validator.c. I have rolled back from
> > 9.8.2-0.62.rc1.el6_9.1 to 9.8.2-0.62.rc1.el6.x86_64 and I now stable again.
> 
> Do you have "dnssec-validation auto" in your configuration?
> 
> I am advised by Red Hat to change this to "no" to prevent the assertion
> until they can get a fix released.

FWIW, we had another crash even with "dnssec-validation no".

Comment 27 Adam Mariš 2017-05-31 07:40:14 UTC

(In reply to Sebastian Hagedorn from comment #26)
> (In reply to Steve Snyder from comment #22)
> > (In reply to Jim Lohiser from comment #20)
> > > We were also seeing the crash with validator.c. I have rolled back from
> > > 9.8.2-0.62.rc1.el6_9.1 to 9.8.2-0.62.rc1.el6.x86_64 and I now stable again.
> > 
> > Do you have "dnssec-validation auto" in your configuration?
> > 
> > I am advised by Red Hat to change this to "no" to prevent the assertion
> > until they can get a fix released.
> 
> FWIW, we had another crash even with "dnssec-validation no".

This is not our official mitigation, there isn't any reliable workaround for this issue which we're aware of. The only way is updating bind package.

Comment 28 Sebastian Hagedorn 2017-05-31 07:54:22 UTC

(In reply to Adam Mariš from comment #27)
> (In reply to Sebastian Hagedorn from comment #26)
> > (In reply to Steve Snyder from comment #22)
> > > (In reply to Jim Lohiser from comment #20)
> > > > We were also seeing the crash with validator.c. I have rolled back from
> > > > 9.8.2-0.62.rc1.el6_9.1 to 9.8.2-0.62.rc1.el6.x86_64 and I now stable again.
> > > 
> > > Do you have "dnssec-validation auto" in your configuration?
> > > 
> > > I am advised by Red Hat to change this to "no" to prevent the assertion
> > > until they can get a fix released.
> > 
> > FWIW, we had another crash even with "dnssec-validation no".
> 
> This is not our official mitigation, there isn't any reliable workaround for
> this issue which we're aware of. The only way is updating bind package.

Thanks, but there is no fixed bind package for RHEL 6, is there? The most recent crash happened with bind-9.8.2-0.62.rc1.el6_9.1. I saw that there is a bind-9.8.2-0.62.rc1.el6_9.2, but the Changelog didn't make it sound like the changes were relevant to this problem.

Are you saying that "dnssec-validation no" doesn't help at all, because then I'd revert to "yes".

Comment 29 Petr Menšík 2017-05-31 08:39:18 UTC

I agree that changelog is not very clear, but bind-9.8.2-0.62.rc1.el6_9.2 is fix for known dnssec validation crashes in bind-9.8.2-0.62.rc1.el6_9.1.

Comment 30 Sebastian Hagedorn 2017-05-31 11:02:54 UTC

(In reply to Petr Menšík from comment #29)
> I agree that changelog is not very clear, but bind-9.8.2-0.62.rc1.el6_9.2 is
> fix for known dnssec validation crashes in bind-9.8.2-0.62.rc1.el6_9.1.

Thanks for the clarification!

Comment 31 errata-xmlrpc 2017-06-28 09:02:05 UTC

This issue has been addressed in the following products:

  Red Hat Enterprise Linux 7.2 Extended Update Support

Via RHSA-2017:1583 https://access.redhat.com/errata/RHSA-2017:1583

Comment 32 errata-xmlrpc 2017-06-28 09:03:26 UTC

This issue has been addressed in the following products:

  Red Hat Enterprise Linux 6.4 Advanced Update Support
  Red Hat Enterprise Linux 6.5 Advanced Update Support
  Red Hat Enterprise Linux 6.5 Telco Extended Update Support
  Red Hat Enterprise Linux 6.6 Telco Extended Update Support
  Red Hat Enterprise Linux 6.7 Extended Update Support
  Red Hat Enterprise Linux 6.6 Advanced Update Support
  Red Hat Enterprise Linux 6.2 Advanced Update Support

Via RHSA-2017:1582 https://access.redhat.com/errata/RHSA-2017:1582