Red Hat Bugzilla – Bug 1476013
Fix regression caused by CVE-2017-3142 fix (broken TSIG-secured transfers).
Last modified: 2018-04-10 07:57:48 EDT
Description of problem: Here, from the horse's mouth: ------------------------------------------------------------------------ Last week ISC issued special security patch releases of BIND to address two TSIG issues (CVE-2017-3142 and CVE-2017-3143.) Unfortunately in doing so we seem to have introduced a regression which can cause interoperability issues with other DNS software. RFC 2845 permits several alternatives for a server to return AXFR (or IXFR) answers that span more than one message. According to the RFC, the first and last message must be signed but signing is optional for messages other than the first and last, so long as at least every hundredth message is signed. BIND signs every outgoing continuation message, as do some other DNS products, but the RFC does not require this and some implementers have chosen differently. Due to our changes for CVE-2017-3142 we have unintentionally caused a problem with BIND's ability to receive an AXFR or IXFR in the case where TSIG is used and not every message is signed. This causes the latest releases of BIND to refuse TSIG-secured transfers and log an error when BIND is receiving AXFR or IXFR data from a server that does not sign every message if the AXFR or IXFR requires more than two messages. To clarify: 1. Zone transfer should still work properly when TSIG is not used. 2. Zone transfer should still work properly when TSIG *is* used when transferring from a BIND master server or another server that signs every message. 3. Problems may occur when transferring from another server if TSIG is used *and* the AXFR or IXFR is more than two messages in length *and* the master server does not sign every message. NSD is an example of a popular DNS product that behaves in this manner [note: NSD's behavior is in compliance with the requirements of the RFC; it is BIND that has introduced a problem here.] Replacement patch versions of BIND will be available shortly to correct this regression. We apologize for this error, which occurred because this interoperability scenario was not properly anticipated in our testing. New checks have been added to ensure that this aspect of zone transfer behavior will be properly exercised in the testing done on future releases. Michael McNally ISC Security Officer ------------------------------------------------------------------------ Then, later from their release notes (7/21 18:08): ------------------------------------------------------------------------ Bug Fixes Fixed a bug that was introduced in an earlier development release which caused multi-packet AXFR and IXFR messages to fail validation if not all packets contained TSIG records; this caused interoperability problems with some other DNS implementations. [RT #45509] ------------------------------------------------------------------------ so it looks like they've fixed it. I don't know how to track down a patch # for you, or I would. Version-Release number of selected component (if applicable): bind-9.9.4-50.el7_3.1 How reproducible: 100% Steps to Reproduce: 1. Look at the case generated from customer. 2. Spend a couple hours verifying what he says is true, and (unsuccessfully) trying to track down a commit number for you. 3. File bug with what you've got. Actual results: Customer unhappy. Expected results: Customer not unhappy. Additional info:
Created attachment 1307570 [details] Modified upstream patch
Hi, thank you for tracking down the upstream commit. Link to upstream patch is https://source.isc.org/cgi-bin/gitweb.cgi?p=bind9.git;a=commit;h=2fc1b8102d4bf02162012c27ab95e98a7438bd8f
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2018:0742