Operational Notification: BIND 9.16.20, 9.17.17, and 9.16.20-S1 can trigger an assertion failure when reading zone data stored in map format

Posting date: 19 August 2021

Program impacted: BIND

Versions affected: BIND 9.16.20, BIND 9.16.20-S1 (Supported Preview Edition), and version 9.17.17 of the 9.17 development branch.

Description:

First and foremost: this notification concerns a bug that ONLY affects servers that are using the "map" format for zone file storage. The "map" format is not used by default, its use on primary servers is generally not recommended, and on secondary servers it is only used when explicitly configured by the operator. If you are not using zones configured with the masterfile-format map option you can safely ignore the rest of this notification.

A change to the map zone file format that was introduced in August 2021 releases (9.16.20, 9.17.17, and version 9.16.20-S1 of BIND Supported Preview Edition) mistakenly failed to change the API version of the storage format. As a consequence, affected BIND versions can exit with an assertion failure when loading zones if those zones are stored in the map zone file format and were originally written by a BIND version produced prior to August 2021.

Zone data stored for BIND's use can be written in a number of formats, which operators can choose among based on their needs. While the most common formats are text (a human-readable format usually preferred for the original and canonical copy of the zone on a primary server) and raw (a faster-loading binary format most often used for zone storage on secondary servers), BIND also supports a zone storage file format called "map". Map files are little more than a dump to disk storage of the data structures making up the in-memory copy of a zone. Servers do not use map format zone storage by default, it requires an explicit configuration choice by the operator.

The map file format is the fastest to load on server startup because it requires the least processing, but because a map format zone file is just a dump of the in-memory representation of a zone, any change to the storage structures used to represent a zone in memory can render zones written using a previous version incompatible. Map zone structures contain header information about the version of the map zone API that wrote them and when a change occurs in the format that API version is supposed to be increased. When that happens, the server knows not to attempt reading the incompatible zones into memory; instead (since map zone storage is overwhelmingly used on secondary servers) named will discard the incompatible copy of the zone and retransfer it from the primary.

Unfortunately in the August 2021 releases, we did not properly increment the map zone API version after making a change to some data structures used to represent the zone in memory. As a result, when attempting to read in a map format zone file written by a prior version, BIND 9.16.20, 9.17.17, and 9.16.20-S1 can terminate with an assertion failure while trying to read a no-longer-compatible map format zone file.

Impact:

We wish to stress again that this issue ONLY affects servers which are using the map format for zone storage. Map format is not selected by default and is an uncommon configuration option. Check your configuration first to see if you are even using it by looking through your configuration for masterfile-format map inside one or more zone declarations. If you are not, then you can safely ignore this operational notification.

If you are using zones stored in map format, however, a server running one of the affected versions can terminate with an assertion failure if it attempts to load an incompatible map-format zone file that it does not realize is incompatible.

An operator who encounters this assertion failure can choose from one of several strategies for dealing with this issue. See the "Solution:" section below.

Solution:

If you have already upgraded to an affected version:

If you have already upgraded to an affected version and have encountered the assertion failure, you can choose from the following options:

• If the only zones using map format storage are zones for which your server is a secondary, you can remove the existing zone files that were stored in map format (preferably by backing them up and moving them to another location, just to be safe) and restart. When the server is started it will retransfer missing zones from the primary and store them in a format with which it can deal. If you have a large number of zones stored in map format or if you have a large number of secondary servers, this may cause a considerable load on the primary while zones are retransferred.
• Revert your server to a version of BIND from before 9.16.19, 9.17.16, or 9.16.19-S1. Those specific versions are not recommended because they are vulnerable to CVE-2021-25218, but the release versions immediately preceding them (9.16.18, 9.17.15, or 9.16.18-S1) are not affected by either issue.
• Since only servers using the map format for zone storage are affected, you will not be affected if your zones are stored as text or raw. The named-compilezone utility provided with BIND can convert existing zone files from one format to another. The problem is that once you have upgraded to an affected version, the named-compilezone utility will not safely read the pre-August map zone files, either. If you require instructions on how to use an older version of named-compilezone to convert map-format zone files to another format, please contact security-officer@isc.org for more information.
• Map zones are not recommended for primary zone storage, but if you have configured a server to store the primary copy of zone data in map format and need help converting to another format, contact us via mail to security-officer@isc.org

If you have not already upgraded to an affected version:

If you have not already upgraded to BIND 9.16.20, 9.17.17, or 9.16.20-S1, you can choose from the following options:

• If the only zones using map format storage are zones for which your server is a secondary, you can remove the existing zone files (preferably by backing them up and moving them to another location, just to be safe) and upgrade. When the server is started after the upgrade it will retransfer zones from the primary and store them in a format with which it can deal.
• Remain on, or revert to, a version of BIND from before 9.16.19, 9.17.16, or 9.16.19-S1. Those specific versions are not recommended because they are vulnerable to CVE-2021-25218, but the release versions immediately preceding them (9.16.18, 9.17.15, or 9.16.18-S1) are not affected by either issue.
• Since only servers using the map format for zone storage are affected, you will not be affected if your zones are stored as text or raw. The named-compilezone utility provided with BIND can convert existing zone files from one format to another. If you require instructions on how to use named-compilezone to convert map-format zone files to another format, please contact security-officer@isc.org for more information.

Related Documents:

1. BIND Administrator Reference Manual section on zone file formats

Do you still have questions? Questions regarding this notification should go to security-officer@isc.org. To report a new issue, please encrypt your message using security-officer@isc.org's PGP key which can be found here: https://www.isc.org/pgpkey/. If you are unable to use encrypted email, you may also report new issues at: https://www.isc.org/reportbug/.

Note:

ISC patches only currently supported versions. When possible we indicate EOL versions affected. (For current information on which versions are actively supported, please see https://www.isc.org/download/.)

ISC Security Vulnerability Disclosure Policy:

Details of our current security advisory policy and practice can be found in the ISC Software Defect and Security Vulnerability Disclosure Policy at https://kb.isc.org/docs/aa-00861.

Legal Disclaimer:

Internet Systems Consortium (ISC) is providing this notice on an "AS IS" basis. No warranty or guarantee of any kind is expressed in this notice and none should be implied. ISC expressly excludes and disclaims any warranties regarding this notice or materials referred to in this notice, including, without limitation, any implied warranty of merchantability, fitness for a particular purpose, absence of hidden defects, or of non-infringement. Your use or reliance on this notice or materials referred to in this notice is at your own risk. ISC may change this notice at any time. A stand-alone copy or paraphrase of the text of this document that omits the document URL is an uncontrolled copy. Uncontrolled copies may lack important information, be out of date, or contain factual errors.