BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2021-05-04T15:10:22Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2617April backports2021-05-04T15:10:22ZMichal NowakApril backportsIn April we had a rule for the `v9_16` branch that only security and QA-approved backports are allowed. This attempted to ensure stability of the 9.16 release, but broke the general rule that backports happen in the same month. The follo...In April we had a rule for the `v9_16` branch that only security and QA-approved backports are allowed. This attempted to ensure stability of the 9.16 release, but broke the general rule that backports happen in the same month. The following merge request were not backported in April (but were tagged as such) and should be backported in the future (i.e. in May).
~"v9.11-S"
- [ ] isc-projects/bind9!4862: "Change default stale-answer-client-timeout to off" (May may be too early)
~"v9.11"
- [ ] isc-projects/bind9!4834: "Resolve "Make calling generic rdata methods consistent""
~"v9.16"
- [ ] isc-projects/bind9!4628: "Improve reliability of the netmgr unit tests"
- [ ] isc-projects/bind9!4792: "Load full certificate chain from a certificate chain file"
- [ ] isc-projects/bind9!4851: "TLS transport code refactoring and unit tests"
- [ ] isc-projects/bind9!4840: "Do not require config.h to use isc/util.h"
- [ ] isc-projects/bind9!4834: "Resolve "Make calling generic rdata methods consistent""
- [ ] isc-projects/bind9!4824: "Call isc__nm_tlsdns_failed_read on tls_error to cleanup the socket"
- [ ] isc-projects/bind9!4820: "Fix dangling uvreq when data is sent from tlsdns_cycle()"
- [ ] isc-projects/bind9!4809: "Fix memory accounting bug in TLSDNS"
- [ ] isc-projects/bind9!4803: "Fix a XoT crash"
MRs should be checked off when backported or ~~crossed out~~ and labels fixed in the MR if not meant to be backported.May 2021 (9.11.32, 9.11.32-S1, 9.16.16, 9.16.16-S1, 9.17.13)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2616Use-after-free in xfrin2021-09-02T10:35:22ZOndřej SurýUse-after-free in xfrinThe logging is trying to lookup the name from already freed object. I thought we already fixed this, but apparently not.
https://gitlab.isc.org/isc-projects/bind9/-/jobs/1623383
```
D:inline:Core was generated by `/builds/isc-projects/...The logging is trying to lookup the name from already freed object. I thought we already fixed this, but apparently not.
https://gitlab.isc.org/isc-projects/bind9/-/jobs/1623383
```
D:inline:Core was generated by `/builds/isc-projects/bind9/bin/named/.libs/named -D inline-ns3 -X named.lock -m'.
D:inline:Program terminated with signal SIGABRT, Aborted.
D:inline:#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
D:inline:[Current thread is 1 (Thread 0x7fa0e386d700 (LWP 23301))]
D:inline:#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
D:inline:#1 0x00007fa0eb21b535 in __GI_abort () at abort.c:79
D:inline:#2 0x0000000000443a9e in abort ()
D:inline:#3 0x00000000004d6dfe in assertion_failed (file=<optimized out>, line=<optimized out>, type=<optimized out>, cond=<optimized out>) at main.c:259
D:inline:#4 0x00007fa0ec14484e in isc_assertion_failed (file=0x2 <error: Cannot access memory at address 0x2>, line=-477983568, line@entry=15631, type=type@entry=isc_assertiontype_require, cond=0x7fa0eb2307bb <__GI_raise+267> "H\213\214$\b\001") at assertions.c:46
D:inline:#5 0x00007fa0ec0155cc in dns_zone_name (zone=0x7b7800050410, buf=buf@entry=0x7fa0e38293f0 "\001", length=length@entry=1055) at zone.c:15631
D:inline:#6 0x00007fa0ec0012fa in xfrin_log (xfr=xfr@entry=0x7b6800060010, level=level@entry=-1, fmt=0x7fa0ec096271 "Transfer status: %s") at xfrin.c:1650
D:inline:#7 0x00007fa0ec000e40 in xfrin_destroy (xfr=xfr@entry=0x7b6800060010) at xfrin.c:1518
D:inline:#8 0x00007fa0ec0009d9 in dns_xfrin_detach (xfrp=0x7fa0e3829b20) at xfrin.c:748
D:inline:#9 0x00007fa0ec002806 in xfrin_recv_done (handle=<optimized out>, handle@entry=0x7b4800072490, result=<optimized out>, result@entry=0, region=<optimized out>, region@entry=0x7fa0e3829b60, cbarg=<optimized out>) at xfrin.c:1492
D:inline:#10 0x00007fa0ec112571 in isc__nm_async_readcb (worker=<optimized out>, ev0=<optimized out>, ev0@entry=0x7fa0e3829bb0) at netmgr/netmgr.c:2411
D:inline:#11 0x00007fa0ec1123a5 in isc__nm_readcb (sock=sock@entry=0x7b74000e0610, uvreq=uvreq@entry=0x7b7000014800, eresult=eresult@entry=0) at netmgr/netmgr.c:2386
D:inline:#12 0x00007fa0ec11b0c6 in isc__nm_tcpdns_processbuffer (sock=sock@entry=0x7b74000e0610) at netmgr/tcpdns.c:795
D:inline:#13 0x00007fa0ec111510 in processbuffer (sock=sock@entry=0x7b74000e0610) at netmgr/netmgr.c:1962
D:inline:#14 0x00007fa0ec11142e in isc__nm_process_sock_buffer (sock=sock@entry=0x7b74000e0610) at netmgr/netmgr.c:1987
D:inline:#15 0x00007fa0ec11b369 in isc__nm_tcpdns_read_cb (stream=<optimized out>, nread=<optimized out>, buf=0x7fa0e3829d30) at netmgr/tcpdns.c:858
D:inline:#16 0x00007fa0eb9bace7 in ?? () from /usr/lib/x86_64-linux-gnu/libuv.so.1
D:inline:#17 0x00007fa0eb9bb908 in ?? () from /usr/lib/x86_64-linux-gnu/libuv.so.1
D:inline:#18 0x00007fa0eb9c04b0 in uv.io_poll () from /usr/lib/x86_64-linux-gnu/libuv.so.1
D:inline:#19 0x00007fa0eb9b1f85 in uv_run () from /usr/lib/x86_64-linux-gnu/libuv.so.1
D:inline:#20 0x00007fa0ec10a39b in nm_thread (worker0=0x7b9c00001690) at netmgr/netmgr.c:558
D:inline:#21 0x00007fa0ec17470a in isc__trampoline_run (arg=0x7b0800020220) at trampoline.c:184
D:inline:#22 0x000000000043e29d in __tsan_thread_start_func ()
D:inline:#23 0x00007fa0eb97dfa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
D:inline:#24 0x00007fa0eb2f24cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
```September 2021 (9.16.21, 9.16.21-S1, 9.17.18)https://gitlab.isc.org/isc-projects/bind9/-/issues/2615ThreadSanitizer: lock-order-inversion in pthread_mutex_lock2022-12-02T12:09:15ZMichal NowakThreadSanitizer: lock-order-inversion in pthread_mutex_lockJob [#1621539](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1621539) failed for cae34f759a90fb36d0efac11c74404a6050c63df on ~"v9.16":
```
WARNING: ThreadSanitizer: lock-order-inversion (potential deadlock)
Cycle in lock order grap...Job [#1621539](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1621539) failed for cae34f759a90fb36d0efac11c74404a6050c63df on ~"v9.16":
```
WARNING: ThreadSanitizer: lock-order-inversion (potential deadlock)
Cycle in lock order graph: M1 (0x000000000000) => M2 (0x000000000000) => M3 (0x000000000000) => M1
Mutex M2 acquired here while holding mutex M1 in thread T1:
#0 pthread_mutex_lock <null>
#1 dns_view_find lib/dns/view.c:1040
#2 dbfind_name lib/dns/adb.c:3833
#3 dns_adb_createfind lib/dns/adb.c:3198
#4 findname lib/dns/resolver.c:3564
#5 fctx_getaddresses lib/dns/resolver.c:3875
#6 fctx_try lib/dns/resolver.c:4264
#7 fctx_timeout lib/dns/resolver.c:4711
#8 dispatch lib/isc/task.c:1153
#9 run lib/isc/task.c:1345
#10 isc__trampoline_run lib/isc/trampoline.c:191
#11 <null> <null>
Mutex M1 previously acquired by the same thread here:
#0 pthread_mutex_lock <null>
#1 find_name_and_lock lib/dns/adb.c:2117
#2 dns_adb_createfind lib/dns/adb.c:3085
#3 findname lib/dns/resolver.c:3564
#4 fctx_getaddresses lib/dns/resolver.c:3875
#5 fctx_try lib/dns/resolver.c:4264
#6 fctx_timeout lib/dns/resolver.c:4711
#7 dispatch lib/isc/task.c:1153
#8 run lib/isc/task.c:1345
#9 isc__trampoline_run lib/isc/trampoline.c:191
#10 <null> <null>
Mutex M3 acquired here while holding mutex M2 in thread T2:
#0 pthread_mutex_lock <null>
#1 dns_zone_flush lib/dns/zone.c:11441
#2 flush lib/dns/zt.c:215
#3 dns_zt_apply lib/dns/zt.c:537
#4 zt_destroy lib/dns/zt.c:221
#5 zt_flushanddetach lib/dns/zt.c:243
#6 dns_zt_flushanddetach lib/dns/zt.c:249
#7 view_flushanddetach lib/dns/view.c:645
#8 dns_view_flushanddetach lib/dns/view.c:687
#9 shutdown_server server.c:9873
#10 dispatch lib/isc/task.c:1153
#11 run lib/isc/task.c:1345
#12 isc__trampoline_run lib/isc/trampoline.c:191
#13 <null> <null>
Mutex M2 previously acquired by the same thread here:
#0 pthread_mutex_lock <null>
#1 view_flushanddetach lib/dns/view.c:642
#2 dns_view_flushanddetach lib/dns/view.c:687
#3 shutdown_server server.c:9873
#4 dispatch lib/isc/task.c:1153
#5 run lib/isc/task.c:1345
#6 isc__trampoline_run lib/isc/trampoline.c:191
#7 <null> <null>
Mutex M1 acquired here while holding mutex M3 in thread T3:
#0 pthread_mutex_lock <null>
#1 violate_locking_hierarchy lib/dns/adb.c:1279
#2 dns_adb_cancelfind lib/dns/adb.c:3457
#3 notify_cancel lib/dns/zone.c:11796
#4 zone_shutdown lib/dns/zone.c:14532
#5 dispatch lib/isc/task.c:1153
#6 run lib/isc/task.c:1345
#7 isc__trampoline_run lib/isc/trampoline.c:191
#8 <null> <null>
Mutex M3 previously acquired by the same thread here:
#0 pthread_mutex_lock <null>
#1 zone_shutdown lib/dns/zone.c:14503
#2 dispatch lib/isc/task.c:1153
#3 run lib/isc/task.c:1345
#4 isc__trampoline_run lib/isc/trampoline.c:191
#5 <null> <null>
Thread T1 (running) created by main thread at:
#0 pthread_create <null>
#1 isc_thread_create lib/isc/pthreads/thread.c:79
#2 isc_taskmgr_create lib/isc/task.c:1435
#3 create_managers main.c:928
#4 setup main.c:1269
#5 main main.c:1572
Thread T2 (running) created by main thread at:
#0 pthread_create <null>
#1 isc_thread_create lib/isc/pthreads/thread.c:79
#2 isc_taskmgr_create lib/isc/task.c:1435
#3 create_managers main.c:928
#4 setup main.c:1269
#5 main main.c:1572
Thread T3 (running) created by main thread at:
#0 pthread_create <null>
#1 isc_thread_create lib/isc/pthreads/thread.c:79
#2 isc_taskmgr_create lib/isc/task.c:1435
#3 create_managers main.c:928
#4 setup main.c:1269
#5 main main.c:1572
SUMMARY: ThreadSanitizer: lock-order-inversion (potential deadlock) in pthread_mutex_lock
```December 2022 (9.16.36, 9.16.36-S1, 9.18.10, 9.19.8)https://gitlab.isc.org/isc-projects/bind9/-/issues/2614Fallthru warnings from gcc in 9.11.292021-04-07T18:39:48ZTimothe LittFallthru warnings from gcc in 9.11.29Compiling 9.11.29 with gcc 8.1.0 (or later) results in a number of warnings of the form:
` warning: this statement may fall through [-Wimplicit-fallthrough=]`
`-Wimplicit-fallthrough=3` is enabled by `-W` (`-Wextra`), which configure...Compiling 9.11.29 with gcc 8.1.0 (or later) results in a number of warnings of the form:
` warning: this statement may fall through [-Wimplicit-fallthrough=]`
`-Wimplicit-fallthrough=3` is enabled by `-W` (`-Wextra`), which configure includes.
These can be annoying - but they can also indicate bugs. Most experienced C coders are careful, but anyone can slip up. They're worth cleaning up.
See https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html for a complete description of the option.
Use comments like `/* FALLS THROUGH */` for legitimate cases. (There's a regexp in the doc listing alternative tags.) */
````
BIND 9.11.29 (Extended Support Version) <id:a35739f>
built by make with '--cache-file=../bind-config.cache' '--with-libtool' '--with-openssl=/usr/local/ssl' '--prefix=/usr' '--enable-largefile' '--with-zlib' '--enable-full-report' '--with-readline=-lreadline -lncurses' '--with-libxml2=/usr' '--with-python=/usr/local/bin/python3' '--with-libjson=/usr/local' '--with-lmdb' '--disable-linux-caps' 'LDFLAGS=-L/usr/local/lib'
compiled by GCC 8.1.0
````https://gitlab.isc.org/isc-projects/bind9/-/issues/2613lib/dns/gen is not deleted on make clean2021-04-09T08:35:26ZArtem Boldarievlib/dns/gen is not deleted on make cleanWhen doing `make clean`, `lib/dns/gen` executable is not being deleted. The issues is present when building at least on Linux or FreeBSD. Not a show stopper, but annoying when building for multiple platforms from the same directory.When doing `make clean`, `lib/dns/gen` executable is not being deleted. The issues is present when building at least on Linux or FreeBSD. Not a show stopper, but annoying when building for multiple platforms from the same directory.April 2021 (9.11.30/9.11.31, 9.11.30-S1/9.11.31-S1, 9.16.14/9.16.15, 9.16.14-S1/9.16.15-S1, 9.17.12)https://gitlab.isc.org/isc-projects/bind9/-/issues/2612CID 330954: Possible Control flow issues in lib/isc/netmgr/tlsstream.c2021-04-09T08:38:37ZMichal NowakCID 330954: Possible Control flow issues in lib/isc/netmgr/tlsstream.cCoverity Scan identified the following issue on `main`:
```
*** CID 330954: Possible Control flow issues (DEADCODE)
/lib/isc/netmgr/tlsstream.c: 423 in tls_do_bio()
417 return;
418 }
419
420 switch (tls_status) {
...Coverity Scan identified the following issue on `main`:
```
*** CID 330954: Possible Control flow issues (DEADCODE)
/lib/isc/netmgr/tlsstream.c: 423 in tls_do_bio()
417 return;
418 }
419
420 switch (tls_status) {
421 case SSL_ERROR_NONE:
422 case SSL_ERROR_ZERO_RETURN:
>>> CID 330954: Possible Control flow issues (DEADCODE)
>>> Execution cannot reach the expression "received_shutdown" inside this statement: "if (sent_shutdown && receiv...".
423 if (sent_shutdown && received_shutdown) {
424 /* clean shutdown */
425 isc_nm_cancelread(sock->outerhandle);
426 isc__nm_tls_close(sock);
427 };
428 return;
```
This likely appeared with 11ed7aac5d9d2d804fa18d98d8c68f0f1bacbb32.May 2021 (9.11.32, 9.11.32-S1, 9.16.16, 9.16.16-S1, 9.17.13)Artem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2611doth system test fails due to SSL error in BIO: 5 unexpected error2021-04-09T08:38:34ZMatthijs Mekkingmatthijs@isc.orgdoth system test fails due to SSL error in BIO: 5 unexpected errorFor example here:
https://gitlab.isc.org/isc-projects/bind9/-/jobs/1614684
```
I:doth:checking DoH query (POST) (6)
02-Apr-2021 12:17:13.870 SSL error in BIO: 5 unexpected error
02-Apr-2021 12:17:13.870 SSL error in BIO: 5 unexpected e...For example here:
https://gitlab.isc.org/isc-projects/bind9/-/jobs/1614684
```
I:doth:checking DoH query (POST) (6)
02-Apr-2021 12:17:13.870 SSL error in BIO: 5 unexpected error
02-Apr-2021 12:17:13.870 SSL error in BIO: 5 unexpected error
02-Apr-2021 12:17:13.870 SSL error in BIO: 5 unexpected error
I:doth:failed
```April 2021 (9.11.30/9.11.31, 9.11.30-S1/9.11.31-S1, 9.16.14/9.16.15, 9.16.14-S1/9.16.15-S1, 9.17.12)Artem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2610bind9 on Docker query acces denied2021-04-01T14:58:53Zyeranosyanvahanbind9 on Docker query acces denied<!--
If the bug you are reporting is potentially security-related - for example,
if it involves an assertion failure or other crash in `named` that can be
triggered repeatedly - then please do *NOT* report it here, but send an
email to [...<!--
If the bug you are reporting is potentially security-related - for example,
if it involves an assertion failure or other crash in `named` that can be
triggered repeatedly - then please do *NOT* report it here, but send an
email to [security-officer@isc.org](security-officer@isc.org).
-->
### Summary
(Summarize the bug encountered concisely.)
### BIND version used
(Paste the output of `named -V`.)
### Steps to reproduce
(How one can reproduce the issue - this is very important.)
### What is the current *bug* behavior?
(What actually happens.)
### What is the expected *correct* behavior?
(What you should see instead.)
### Relevant configuration files
(Paste any relevant configuration files - please use code blocks (```)
to format console output. If submitting the contents of your
configuration file in a non-confidential Issue, it is advisable to
obscure key secrets: this can be done automatically by using
`named-checkconf -px`.)
### Relevant logs and/or screenshots
(Paste any relevant logs - please use code blocks (```) to format console
output, logs, and code, as it's very hard to read otherwise.)
### Possible fixes
(If you can, link to the line of code that might be responsible for the
problem.)https://gitlab.isc.org/isc-projects/bind9/-/issues/2608Change stale-answer-client-timeout default to off2021-04-22T07:30:06ZMatthijs Mekkingmatthijs@isc.orgChange stale-answer-client-timeout default to offUsing "stale-answer-client-timeout" turns out to have unforeseen
negative consequences (see e.g. #2594). The team is in agreement that
disabling it by default is a prudent thing to do for the time being.Using "stale-answer-client-timeout" turns out to have unforeseen
negative consequences (see e.g. #2594). The team is in agreement that
disabling it by default is a prudent thing to do for the time being.April 2021 (9.11.30/9.11.31, 9.11.30-S1/9.11.31-S1, 9.16.14/9.16.15, 9.16.14-S1/9.16.15-S1, 9.17.12)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/2607Remove custom ISC SPNEGO implementation2021-04-02T06:06:24ZOndřej SurýRemove custom ISC SPNEGO implementationThe SPNEGO mechanism is available in both major implementations of Kerberos protocol:
* MIT Kerberos 5 since version 1.5
* Heimdal Kerberos since version 0.7
e.g. both are available since 2006-2007.The SPNEGO mechanism is available in both major implementations of Kerberos protocol:
* MIT Kerberos 5 since version 1.5
* Heimdal Kerberos since version 0.7
e.g. both are available since 2006-2007.April 2021 (9.11.30/9.11.31, 9.11.30-S1/9.11.31-S1, 9.16.14/9.16.15, 9.16.14-S1/9.16.15-S1, 9.17.12)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2606Remove support for builtin atomics on legacy clang compilers2021-07-08T08:06:18ZDiego dos Santos FronzaRemove support for builtin atomics on legacy clang compilersThe support for legacy clang builtin atomics has been never needed and used before, the implementation itself was broken, evidencing the lack of use cases.The support for legacy clang builtin atomics has been never needed and used before, the implementation itself was broken, evidencing the lack of use cases.July 2021 (9.11.34, 9.11.34-S1, 9.16.19, 9.16.19-S1, 9.17.16)Diego dos Santos FronzaDiego dos Santos Fronzahttps://gitlab.isc.org/isc-projects/bind9/-/issues/2605dangling HTTPS socket when ALPN negotiation fails2021-09-02T12:43:39ZOndřej Surýdangling HTTPS socket when ALPN negotiation fails```
(main $%=)$ bin/dig/dig +https
;; Connection to 10.10.10.1#443(10.10.10.1) for . failed: ALPN for HTTP/2 failed.
;; Connection to 10.10.10.1#443(10.10.10.1) for . failed: ALPN for HTTP/2 failed.
;; Connection to 10.10.10.1#443(10.10....```
(main $%=)$ bin/dig/dig +https
;; Connection to 10.10.10.1#443(10.10.10.1) for . failed: ALPN for HTTP/2 failed.
;; Connection to 10.10.10.1#443(10.10.10.1) for . failed: ALPN for HTTP/2 failed.
;; Connection to 10.10.10.1#443(10.10.10.1) for . failed: ALPN for HTTP/2 failed.
```September 2021 (9.16.21, 9.16.21-S1, 9.17.18)https://gitlab.isc.org/isc-projects/bind9/-/issues/2604[CVE-2021-25216] ZDI-CAN-13347: A second vulnerability in BIND's GSSAPI secur...2021-04-29T10:36:42ZOndřej Surý[CVE-2021-25216] ZDI-CAN-13347: A second vulnerability in BIND's GSSAPI security policy negotiation can be targeted by a buffer overflow attack### CVE-specific actions
- [x] [Assign a CVE identifier](#note_204258)
- [x] [Determine CVSS score](#note_204769)
- [x] [Determine the range of BIND versions affected (including the Subscription Edition)](#note_204773)
- [x] [De...### CVE-specific actions
- [x] [Assign a CVE identifier](#note_204258)
- [x] [Determine CVSS score](#note_204769)
- [x] [Determine the range of BIND versions affected (including the Subscription Edition)](#note_204773)
- [x] [Determine whether workarounds for the problem exists](#note_204776)
- [x] Prepare a detailed description of the problem which should include the following by default:
- [instructions for reproducing the problem (a system test is good enough)](isc-private/bind9!287)
- [explanation of code flow which triggers the problem (a system test is *not* good enough)](#note_205320)
- [x] [Prepare a private merge request containing the following items in separate commits:](isc-private/bind9!283)
- a test for the issue (may be moved to a separate merge request for deferred merging)
- a fix for the issue
- documentation updates (`CHANGES`, [release notes](#note_205396), anything else applicable)
- [x] Ensure the merge request from the previous step is reviewed by SWENG staff and has no outstanding discussions
- [x] Ensure the documentation changes introduced by the merge request addressing the problem are reviewed by Support and Marketing staff
- [x] Prepare backports of the merge request addressing the problem for all affected (and still maintained) BIND branches (backporting might affect the issue's scope and/or description)
- [x] Prepare a standalone patch for the last stable release of each affected (and still maintained) BIND branch
### Release-specific actions
- [x] Create/update the private issue containing links to fixes & reproducers for all CVEs fixed in a given release cycle
- [x] Reserve a block of `CHANGES` placeholders once the complete set of vulnerabilities fixed in a given release cycle is determined
- [x] Ensure the merge requests containing CVE fixes are merged into `security-*` branches in CVE identifier order
---
## CVSS
8.1: AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
## ABSTRACT
Trend Micro's Zero Day Initiative has identified a vulnerability affecting the following products:
ISC - BIND
## VULNERABILITY DETAILS
* Version tested:9.16.13
* Installer file:https://downloads.isc.org/isc/bind9/9.16.13/bind-9.16.13.tar.xz
* Platform tested:debian-10.8.0-i386-netinst
---
### Analysis
```
integer overflow exist in der_get_oid() and leads to a wild-copy
it affected 32-bit only
```
~~~C++
lib/dns/spnego.c
der_get_oid(const unsigned char *p, size_t len, oid *data, size_t *size) {
int n;
size_t oldlen = len;
data->components = NULL;
data->length = 0;
if (len < 1U) {
return (ASN1_OVERRUN);
}
[1] data->components = malloc((len + 1) * sizeof(*data->components));
...
}
~~~
On 32 bit platforms 'len' is unsigned integer.
On line #1 integer overflow occurs if we set 'len' to 0x40000000, thus small buffer will be allocated.
Later it will be overwritten in oid decoding loop
debug log
```
Thread 2 "isc-net-0000" hit Breakpoint 2, 0x00d4dc9e in der_get_oid ()
1: x/i $pc
=> 0xd4dc9e <der_get_oid+171>: add eax,0x1
(gdb) i r $eax
eax 0x40000000 1073741824
(gdb) si
0x00d4dca1 in der_get_oid ()
1: x/i $pc
=> 0xd4dca1 <der_get_oid+174>: shl eax,0x2
(gdb) si
0x00d4dca4 in der_get_oid ()
1: x/i $pc
=> 0xd4dca4 <der_get_oid+177>: sub esp,0xc
(gdb) si
0x00d4dca7 in der_get_oid ()
1: x/i $pc
=> 0xd4dca7 <der_get_oid+180>: push eax
(gdb) si
0x00d4dca8 in der_get_oid ()
1: x/i $pc
=> 0xd4dca8 <der_get_oid+181>: call 0x5aa260 <malloc@plt>
(gdb) i r $eax
eax 0x4 4 // integer overflowed
(gdb) bt
#0 0x00d4dca8 in der_get_oid ()
#1 0x00d4f03a in decode_oid ()
#2 0x00d45878 in decode_MechType ()
#3 0x00d46108 in decode_MechTypeList ()
#4 0x00d478c0 in decode_NegTokenInit ()
#5 0x00d4c117 in gss_accept_sec_context_spnego ()
#6 0x00d0530a in dst_gssapi_acceptctx ()
#7 0x00b89bc8 in process_gsstkey ()
#8 0x00b8c332 in dns_tkey_processquery ()
#9 0x00712d33 in ns_query_start ()
#10 0x006998ed in ns.client_request ()
#11 0x00e17092 in isc.nm_async_readcb ()
#12 0x00e166c2 in isc.nm_readcb ()
#13 0x00e4266e in processbuffer ()
#14 0x00e4a2f5 in process_sock_buffer ()
#15 0x00e43038 in read_cb ()
#16 0xb740a727 in ?? () from /lib/i386-linux-gnu/libuv.so.1
#17 0xb740b2b7 in ?? () from /lib/i386-linux-gnu/libuv.so.1
#18 0xb7410468 in uv.io_poll () from /lib/i386-linux-gnu/libuv.so.1
#19 0xb7401146 in uv_run () from /lib/i386-linux-gnu/libuv.so.1
#20 0x00e068e7 in nm_thread ()
#21 0x00e9c1e0 in isc.trampoline_run ()
#22 0xb793d321 in ?? () from /lib/i386-linux-gnu/libasan.so.5
#23 0xb73cdfd2 in start_thread (arg=<optimized out>) at pthread_create.c:486
#24 0xb72b96d6 in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:108
```
ASAN report
```
=================================================================
==6064==ERROR: AddressSanitizer: heap-buffer-overflow on address 0xb4a23154 at pc 0x00d4de48 bp 0xb26f8a38 sp 0xb26f8a2c
WRITE of size 4 at 0xb4a23154 thread T1
#0 0xd4de47 in der_get_oid (/var/bind/sbin/named+0x868e47)
#1 0xd4f039 in decode_oid (/var/bind/sbin/named+0x86a039)
#2 0xd45877 in decode_MechType (/var/bind/sbin/named+0x860877)
#3 0xd46107 in decode_MechTypeList (/var/bind/sbin/named+0x861107)
#4 0xd478bf in decode_NegTokenInit (/var/bind/sbin/named+0x8628bf)
#5 0xd4c116 in gss_accept_sec_context_spnego (/var/bind/sbin/named+0x867116)
#6 0xd05309 in dst_gssapi_acceptctx (/var/bind/sbin/named+0x820309)
#7 0xb89bc7 in process_gsstkey (/var/bind/sbin/named+0x6a4bc7)
#8 0xb8c331 in dns_tkey_processquery (/var/bind/sbin/named+0x6a7331)
#9 0x712d32 in ns_query_start (/var/bind/sbin/named+0x22dd32)
#10 0x6998ec in ns__client_request (/var/bind/sbin/named+0x1b48ec)
#11 0xe17091 in isc__nm_async_readcb (/var/bind/sbin/named+0x932091)
#12 0xe166c1 in isc__nm_readcb (/var/bind/sbin/named+0x9316c1)
#13 0xe4266d in processbuffer (/var/bind/sbin/named+0x95d66d)
#14 0xe4a2f4 in process_sock_buffer (/var/bind/sbin/named+0x9652f4)
#15 0xe43037 in read_cb (/var/bind/sbin/named+0x95e037)
#16 0xb740a726 (/lib/i386-linux-gnu/libuv.so.1+0x17726)
#17 0xb740b2b6 (/lib/i386-linux-gnu/libuv.so.1+0x182b6)
#18 0xb7410467 in uv__io_poll (/lib/i386-linux-gnu/libuv.so.1+0x1d467)
#19 0xb7401145 in uv_run (/lib/i386-linux-gnu/libuv.so.1+0xe145)
#20 0xe068e6 in nm_thread (/var/bind/sbin/named+0x9218e6)
#21 0xe9c1df in isc__trampoline_run (/var/bind/sbin/named+0x9b71df)
#22 0xb793d320 (/lib/i386-linux-gnu/libasan.so.5+0x4a320)
#23 0xb73cdfd1 in start_thread /build/glibc-Stc26X/glibc-2.28/nptl/pthread_create.c:486
#24 0xb72b96d5 in __clone (/lib/i386-linux-gnu/libc.so.6+0xfa6d5)
0xb4a23154 is located 0 bytes to the right of 4-byte region [0xb4a23150,0xb4a23154)
allocated by thread T1 here:
#0 0xb79de5d4 in __interceptor_malloc (/lib/i386-linux-gnu/libasan.so.5+0xeb5d4)
#1 0xd4dcac in der_get_oid (/var/bind/sbin/named+0x868cac)
#2 0xd4f039 in decode_oid (/var/bind/sbin/named+0x86a039)
#3 0xd45877 in decode_MechType (/var/bind/sbin/named+0x860877)
#4 0xd46107 in decode_MechTypeList (/var/bind/sbin/named+0x861107)
#5 0xd478bf in decode_NegTokenInit (/var/bind/sbin/named+0x8628bf)
#6 0xd4c116 in gss_accept_sec_context_spnego (/var/bind/sbin/named+0x867116)
#7 0xd05309 in dst_gssapi_acceptctx (/var/bind/sbin/named+0x820309)
#8 0xb89bc7 in process_gsstkey (/var/bind/sbin/named+0x6a4bc7)
#9 0xb8c331 in dns_tkey_processquery (/var/bind/sbin/named+0x6a7331)
#10 0x712d32 in ns_query_start (/var/bind/sbin/named+0x22dd32)
#11 0x6998ec in ns__client_request (/var/bind/sbin/named+0x1b48ec)
#12 0xe17091 in isc__nm_async_readcb (/var/bind/sbin/named+0x932091)
#13 0xe166c1 in isc__nm_readcb (/var/bind/sbin/named+0x9316c1)
#14 0xe4266d in processbuffer (/var/bind/sbin/named+0x95d66d)
#15 0xe4a2f4 in process_sock_buffer (/var/bind/sbin/named+0x9652f4)
#16 0xe43037 in read_cb (/var/bind/sbin/named+0x95e037)
#17 0xb740a726 (/lib/i386-linux-gnu/libuv.so.1+0x17726)
Thread T1 created by T0 here:
#0 0xb79c6b50 in pthread_create (/lib/i386-linux-gnu/libasan.so.5+0xd3b50)
#1 0xed85a5 in isc_thread_create (/var/bind/sbin/named+0x9f35a5)
#2 0xe03a94 in isc_nm_start (/var/bind/sbin/named+0x91ea94)
#3 0x5cc8f5 in create_managers (/var/bind/sbin/named+0xe78f5)
#4 0x5cd5ea in setup (/var/bind/sbin/named+0xe85ea)
#5 0x5cdc89 in main (/var/bind/sbin/named+0xe8c89)
#6 0xb71d9b40 in __libc_start_main ../csu/libc-start.c:308
SUMMARY: AddressSanitizer: heap-buffer-overflow (/var/bind/sbin/named+0x868e47) in der_get_oid
Shadow bytes around the buggy address:
0x369445d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x369445e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x369445f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x36944600: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x36944610: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
=>0x36944620: fa fa fa fa fa fa fa fa fa fa[04]fa fa fa 00 fa
0x36944630: fa fa 00 01 fa fa 00 04 fa fa 04 fa fa fa fd fa
0x36944640: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa
0x36944650: fa fa fd fa fa fa fd fd fa fa fd fd fa fa fd fa
0x36944660: fa fa fd fa fa fa fd fd fa fa fd fa fa fa fd fd
0x36944670: fa fa fd fd fa fa fd fa fa fa fd fa fa fa fd fd
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
==6064==ABORTING
```
## CREDIT
This vulnerability was discovered by:
Anonymous working with Trend Micro Zero Day Initiative
## FURTHER DETAILS
If supporting files were contained with this report they are provided within a password protected ZIP file. The password is the ZDI candidate number in the form: ZDI-CAN-XXXX where XXXX is the ID number.
Please confirm receipt of this report. We expect all vendors to remediate ZDI vulnerabilities within 120 days of the reported date. If you are ready to release a patch at any point leading up to the deadline, please coordinate with us so that we may release our advisory detailing the issue. If the 120-day deadline is reached and no patch has been made available we will release a limited public advisory with our own mitigations, so that the public can protect themselves in the absence of a patch. Please keep us updated regarding the status of this issue and feel free to contact us at any time:
Zero Day Initiative
zdi-disclosures@trendmicro.com
The PGP key used for all ZDI vendor communications is available from:
http://www.zerodayinitiative.com/documents/disclosures-pgp-key.asc
## INFORMATION ABOUT THE ZDI
Established by TippingPoint and acquired by Trend Micro, the Zero Day Initiative (ZDI) neither re-sells vulnerability details nor exploit code. Instead, upon notifying the affected product vendor, the ZDI provides its Trend Micro TippingPoint customers with zero day protection through its intrusion prevention technology. Explicit details regarding the specifics of the vulnerability are not exposed to any parties until an official vendor patch is publicly available.
Please contact us for further details or refer to:
http://www.zerodayinitiative.com
## DISCLOSURE POLICY
Our vulnerability disclosure policy is available online at:
http://www.zerodayinitiative.com/advisories/disclosure_policy/
## ATTACHMENTS
[redacted]April 2021 (9.11.30/9.11.31, 9.11.30-S1/9.11.31-S1, 9.16.14/9.16.15, 9.16.14-S1/9.16.15-S1, 9.17.12)https://gitlab.isc.org/isc-projects/bind9/-/issues/2603There is no way to have no dnssec-policy.2021-06-16T20:19:29ZMark AndrewsThere is no way to have no dnssec-policy.bin/named/config.c has `dnssec-policy "none";` which turns on kasp for **every** zone even those being externally managed.bin/named/config.c has `dnssec-policy "none";` which turns on kasp for **every** zone even those being externally managed.May 2021 (9.11.32, 9.11.32-S1, 9.16.16, 9.16.16-S1, 9.17.13)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/2602dnssec-policy publish dynamic zone without NSEC3 despite policy2021-04-12T07:04:38ZMarc Dequènes (Duck)dnssec-policy publish dynamic zone without NSEC3 despite policy### Summary
History: I had a problem with dynamic zones (migrated from dnssec-keymgr) on a server with RRs which stopped being validated properly but the logs did not go far enough to find the origin of the problem. On one zone that I c...### Summary
History: I had a problem with dynamic zones (migrated from dnssec-keymgr) on a server with RRs which stopped being validated properly but the logs did not go far enough to find the origin of the problem. On one zone that I could not fix with dnssec-signzone I decided to recreate it from scratch.
All seemed to go well, the checkds went well, and RRSIGs are published but NSEC3 are not and the zone is not secure.
### BIND version used
```
BIND 9.16.11-Debian (Stable Release) <id:9ff601b>
running on Linux x86_64 4.19.0-10-amd64 #1 SMP Debian 4.19.132-1 (2020-07-24)
built by make with '--build=x86_64-linux-gnu' '--prefix=/usr' '--includedir=/usr/include' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--sysconfdir=/etc' '--localstatedir=/var' '--disable-silent-rules' '--libdir=/usr/lib/x86_64-linux-gnu' '--runstatedir=/run' '--disable-maintainer-mode' '--disable-dependency-tracking' '--libdir=/usr/lib/x86_64-linux-gnu' '--sysconfdir=/etc/bind' '--with-python=python3' '--localstatedir=/' '--enable-threads' '--enable-largefile' '--with-libtool' '--enable-shared' '--enable-static' '--with-gost=no' '--with-openssl=/usr' '--with-gssapi=/usr' '--with-libidn2' '--with-json-c' '--with-lmdb=/usr' '--with-gnu-ld' '--with-maxminddb' '--with-atf=no' '--enable-ipv6' '--enable-rrl' '--enable-filter-aaaa' '--disable-native-pkcs11' '--enable-dnstap' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -fdebug-prefix-map=/build/bind9-DpdRXh/bind9-9.16.11=. -fstack-protector-strong -Wformat -Werror=format-security -fno-strict-aliasing -fno-delete-null-pointer-checks -DNO_VERSION_DATE -DDIG_SIGCHASE' 'LDFLAGS=-Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'
compiled by GCC 8.3.0
compiled with OpenSSL version: OpenSSL 1.1.1d 10 Sep 2019
linked to OpenSSL version: OpenSSL 1.1.1d 10 Sep 2019
compiled with libuv version: 1.24.1
linked to libuv version: 1.24.1
compiled with libxml2 version: 2.9.4
linked to libxml2 version: 20904
compiled with json-c version: 0.12.1
linked to json-c version: 0.12.1
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
linked to maxminddb version: 1.3.2
compiled with protobuf-c version: 1.3.1
linked to protobuf-c version: 1.3.1
threads support is enabled
default paths:
named configuration: /etc/bind/named.conf
rndc configuration: /etc/bind/rndc.conf
DNSSEC root key: /etc/bind/bind.keys
nsupdate session key: //run/named/session.key
named PID file: //run/named/named.pid
named lock file: //run/named/named.lock
geoip-directory: /usr/share/GeoIP
```
### Steps to reproduce
* After stopping bind I removed everything about the old zone, journals, keys and so on
* I recreated a basic zone with just a handful of RRs I need (SOA, 3 NS, 3 TLSA entries), nothing related to DNSSEC
* I defined the zone with the dnssec-policy I us for all my zones and works fine for non-dynamic zones so far
* started bind
* waited for CDS to be published
* rndc dnssec -checkds -key 32826 published _kage.duckcorp.org
* waited for the status to all switch to omnipresent
* used dig and also delv to check the zone
### What is the current *bug* behavior?
```
delv +rtrace +dnssec @ns1.duckcorp.org SOA _kage.duckcorp.org
;; fetch: ns1.duckcorp.org/A
;; fetch: ns1.duckcorp.org/AAAA
;; fetch: ns1.duckcorp.org.hq.duckcorp.org/A
;; fetch: ns1.duckcorp.org.hq.duckcorp.org/AAAA
;; fetch: ns1.duckcorp.org.duckcorp.org/A
;; fetch: ns1.duckcorp.org.duckcorp.org/AAAA
;; fetch: _kage.duckcorp.org/SOA
;; fetch: org/DS
;; fetch: ./DNSKEY
;; fetch: duckcorp.org/DS
;; fetch: org/DNSKEY
;; fetch: _kage.duckcorp.org/DS
;; fetch: duckcorp.org/DNSKEY
;; insecurity proof failed resolving '_kage.duckcorp.org/SOA/IN': 2001:67c:1740:9016::c111:c0d3#53
;; validating _kage.duckcorp.org/SOA: got insecure response; parent indicates it should be secure
;; insecurity proof failed resolving '_kage.duckcorp.org/SOA/IN': 193.200.43.105#53
;; resolution failed: insecurity proof failed
```
Confirmed by dnsviz: https://dnsviz.net/d/_kage.duckcorp.org/dnssec/
Even after `rndc sync -clean _kage.duckcorp.org` there is no NSEC3 (or even NSEC) RRs, and no NSEC3PARAM in the zone file.
### What is the expected *correct* behavior?
I expected the NSEC3PARAM RR to be added in the zone according to policy and then NSEC3 RRs to be generated.
### Relevant configuration files
The zone:
```
zone "_kage.duckcorp.org" IN {
type master;
allow-transfer { key duckcorp-internal; };
update-policy { <many-grants> };
file "/var/cache/bind/masters/_kage.duckcorp.org.zone";
dnssec-policy "generated";
};
```
And the policy:
```
dnssec-policy "generated" {
keys {
ksk key-directory lifetime P1Y algorithm rsasha512 4096;
zsk key-directory lifetime 30d algorithm rsasha512 2048;
};
max-zone-ttl PT1H;
nsec3param iterations 5 optout no salt-length 8;
};
```
### Relevant logs and/or screenshots
(Paste any relevant logs - please use code blocks (```) to format console
output, logs, and code, as it's very hard to read otherwise.)
```
# rndc dnssec -status _kage.duckcorp.org
dnssec-policy: generated
current time: Sun Mar 28 17:24:17 2021
key: 32826 (RSASHA512), KSK
published: yes - since Sat Mar 27 08:56:19 2021
key signing: yes - since Sat Mar 27 08:56:19 2021
Next rollover scheduled on Sun Mar 27 07:51:19 2022
- goal: omnipresent
- dnskey: omnipresent
- ds: omnipresent
- key rrsig: omnipresent
key: 63491 (RSASHA512), ZSK
published: yes - since Sat Mar 27 08:56:19 2021
zone signing: yes - since Sat Mar 27 08:56:19 2021
Next rollover scheduled on Mon Apr 26 07:51:19 2021
- goal: omnipresent
- dnskey: omnipresent
- zone rrsig: omnipresent
```
But the zone is not considered secure for some reason:
```
# rndc zonestatus _kage.duckcorp.org
name: _kage.duckcorp.org
type: master
files: /var/cache/bind/masters/_kage.duckcorp.org.zone
serial: 10056
nodes: 5
last loaded: Sat, 27 Mar 2021 10:15:37 GMT
secure: no
key maintenance: automatic
next key event: Mon, 26 Apr 2021 05:51:19 GMT
dynamic: yes
frozen: no
reconfigurable via modzone: no
```
```
27-Mar-2021 08:56:19.477 dnssec: info: zone _kage.duckcorp.org/IN: reconfiguring zone keys
27-Mar-2021 08:56:21.241 dnssec: info: keymgr: DNSKEY _kage.duckcorp.org/RSASHA512/32826 (KSK) created for policy generated
27-Mar-2021 08:56:21.473 dnssec: info: keymgr: DNSKEY _kage.duckcorp.org/RSASHA512/63491 (ZSK) created for policy generated
27-Mar-2021 08:56:21.473 dnssec: info: Fetching _kage.duckcorp.org/RSASHA512/32826 (KSK) from key repository.
27-Mar-2021 08:56:21.473 dnssec: info: DNSKEY _kage.duckcorp.org/RSASHA512/32826 (KSK) is now published
27-Mar-2021 08:56:21.473 dnssec: info: DNSKEY _kage.duckcorp.org/RSASHA512/32826 (KSK) is now active
27-Mar-2021 08:56:21.473 dnssec: info: Fetching _kage.duckcorp.org/RSASHA512/63491 (ZSK) from key repository.
27-Mar-2021 08:56:21.473 dnssec: info: DNSKEY _kage.duckcorp.org/RSASHA512/63491 (ZSK) is now published
27-Mar-2021 08:56:21.473 dnssec: info: DNSKEY _kage.duckcorp.org/RSASHA512/63491 (ZSK) is now active
27-Mar-2021 08:56:21.553 dnssec: info: zone _kage.duckcorp.org/IN: next key event: 27-Mar-2021 11:01:19.477
27-Mar-2021 11:01:19.480 dnssec: info: zone _kage.duckcorp.org/IN: reconfiguring zone keys
27-Mar-2021 11:01:19.580 dnssec: info: zone _kage.duckcorp.org/IN: next key event: 27-Mar-2021 12:01:19.480
27-Mar-2021 12:01:19.483 dnssec: info: zone _kage.duckcorp.org/IN: reconfiguring zone keys
27-Mar-2021 12:01:19.483 dnssec: info: zone _kage.duckcorp.org/IN: next key event: 28-Mar-2021 14:28:24.483
28-Mar-2021 06:12:18.696 dnssec: info: zone _kage.duckcorp.org/IN: reconfiguring zone keys
28-Mar-2021 06:12:18.756 dnssec: info: zone _kage.duckcorp.org/IN: next key event: 28-Mar-2021 14:28:24.696
28-Mar-2021 14:28:24.697 dnssec: info: zone _kage.duckcorp.org/IN: reconfiguring zone keys
28-Mar-2021 14:28:24.737 dnssec: info: zone _kage.duckcorp.org/IN: next key event: 26-Apr-2021 07:51:19.697
```
### Possible fixes
I have no idea how to fix this problem. I suppose the NSEC3PARAM RR is not created in dynamic zones for some reason and then NSEC3 RRs are never created. Maybe inserting it manually would solve the problem but I have not tried this yet.https://gitlab.isc.org/isc-projects/bind9/-/issues/2601typo in definition of atomic_exchange_explicit for Clang on Unix2021-03-31T21:40:56ZRoland Illigtypo in definition of atomic_exchange_explicit for Clang on Unix### Summary
stdatomic.h says:
~~~c
#define atomic_exchange_explicit(obj, desired, order) \
__c11_atomic_exchange_explicit(obj, expected, order)
~~~
This only works if the second argument to that macro is the identifier 'expected'.
Oth...### Summary
stdatomic.h says:
~~~c
#define atomic_exchange_explicit(obj, desired, order) \
__c11_atomic_exchange_explicit(obj, expected, order)
~~~
This only works if the second argument to that macro is the identifier 'expected'.
Otherwise this (hopefully) produces a 'no such local variable' message from the compiler.
### Steps to reproduce
Compile `queue.c` with compiler options that trigger the faulty macro.
The original code in `queue.c` is:
~~~c
item = atomic_exchange(&(lh->items[idx]),
(uintptr_t)&queue->taken);
~~~
This produces the following line after preprocessing:
~~~c
item = __c11_atomic_exchange_explicit(&(lh->items[idx]), expected, memory_order_seq_cst);
~~~
This line does not contain `queue->taken` anymore.
### What is the current *bug* behavior?
Compilation fails because `expected` is not a defined variable.
### What is the expected *correct* behavior?
Compilation succeeds.
### Possible fixes
Write 'desired' instead of 'expected'.Diego dos Santos FronzaDiego dos Santos Fronzahttps://gitlab.isc.org/isc-projects/bind9/-/issues/2600general: error: managed-keys-zone: dns_journal_compact failed: no more2021-04-26T10:22:12ZJean-Christophe Manciotgeneral: error: managed-keys-zone: dns_journal_compact failed: no more- Ubuntu hirsute and Debian bullseye
- bind9 9.17.11
```
# echo 'q' | sudo systemctl --no-pager --full status named
● named.service - BIND Domain Name Server
Loaded: loaded (/lib/systemd/system/named.service; enabled; vendor preset...- Ubuntu hirsute and Debian bullseye
- bind9 9.17.11
```
# echo 'q' | sudo systemctl --no-pager --full status named
● named.service - BIND Domain Name Server
Loaded: loaded (/lib/systemd/system/named.service; enabled; vendor preset: enabled)
Active: active (running) since Fri 2021-03-26 08:39:18 CET; 19min ago
Docs: man:named(8)
Main PID: 1469485 (named)
Tasks: 14 (limit: 9260)
Memory: 27.3M
CGroup: /system.slice/named.service
└─1469485 /usr/sbin/named -f -u bind
Mar 26 08:39:18 hostname named[1469485]: 26-Mar-2021 08:39:18.331 zoneload: info: zone 0.in-addr.arpa/IN: loaded serial 2020100901
Mar 26 08:39:18 hostname named[1469485]: 26-Mar-2021 08:39:18.339 zoneload: info: zone 127.in-addr.arpa/IN: loaded serial 2020100901
Mar 26 08:39:18 hostname named[1469485]: 26-Mar-2021 08:39:18.347 zoneload: info: zone 255.in-addr.arpa/IN: loaded serial 2020100901
...
Mar 26 08:39:18 hostname named[1469485]: 26-Mar-2021 08:39:18.355 zoneload: info: zone localhost/IN: loaded serial 2020100901
Mar 26 08:39:18 hostname named[1469485]: 26-Mar-2021 08:39:18.367 general: notice: all zones loaded
Mar 26 08:39:18 hostname named[1469485]: 26-Mar-2021 08:39:18.375 general: notice: running
Mar 26 08:39:18 hostname named[1469485]: 26-Mar-2021 08:39:18.375 general: info: zone sdxlive.com/IN (signed): receive_secure_serial: unchanged
Mar 26 08:39:48 hostname named[1469485]: 26-Mar-2021 08:39:48.491 general: error: managed-keys-zone: dns_journal_compact failed: no more
```
This issue appeared with 9.17.11 and was not present with previous releases.
Is there a workaround?April 2021 (9.11.30/9.11.31, 9.11.30-S1/9.11.31-S1, 9.16.14/9.16.15, 9.16.14-S1/9.16.15-S1, 9.17.12)https://gitlab.isc.org/isc-projects/bind9/-/issues/2599Run "less stable" unit tests in CI2022-02-25T13:49:37ZMichal NowakRun "less stable" unit tests in CIThere are net manager unit tests which are at the moment "less stable" _in the CI_ than the rest of unit tests. Running them by default means CI pipelines results are overall less stable but those "less stable" unit test need to be run s...There are net manager unit tests which are at the moment "less stable" _in the CI_ than the rest of unit tests. Running them by default means CI pipelines results are overall less stable but those "less stable" unit test need to be run somewhere for them to ever become stable enough. The discussion started on [Mattermost](https://mattermost.isc.org/isc/channels/bind9/qxx36uts4jyxmmtt8yijf5598h). The [suggested solution](https://mattermost.isc.org/isc/pl/nz9ruc73dtb1uf3b37jwjm7pga) is to run them on AWS stress test machines.March 2022 (9.11.37, 9.11.37-S1, 9.16.27, 9.16.27-S1, 9.18.1)Michal NowakMichal Nowakhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2597Make calling generic rdata methods consistent2021-03-29T14:02:33ZMark AndrewsMake calling generic rdata methods consistentApril 2021 (9.11.30/9.11.31, 9.11.30-S1/9.11.31-S1, 9.16.14/9.16.15, 9.16.14-S1/9.16.15-S1, 9.17.12)https://gitlab.isc.org/isc-projects/bind9/-/issues/2596dnssec-policy unexpectedly breaks a DNSSEC-signed zone by creating new keys i...2021-05-11T07:35:16ZCathy Almonddnssec-policy unexpectedly breaks a DNSSEC-signed zone by creating new keys if it can't access the current keysetAs noted in [Support ticket #18133](https://support.isc.org/Ticket/Display.html?id=18133) it's possible to quite thoroughly 'break' a DNSSEC-signed zone if you're using dnssec-policy and the private keys are inaccessible when named start...As noted in [Support ticket #18133](https://support.isc.org/Ticket/Display.html?id=18133) it's possible to quite thoroughly 'break' a DNSSEC-signed zone if you're using dnssec-policy and the private keys are inaccessible when named starts up (and I would not be surprised if this also happens when doing a reconfig or a reload zone).
This could be quite serious if the same thing happens because of a temporary glitch with access to keys stored in an HSM. Although the keys were inaccessible, this could have been remedied.
The creation and addition to the zone of new keys, complete with the failure to be able to refresh the DNSSEY RRset RRSIGs from the old KSK (which was the only key with a DS RR in the parent zone) was catastrophic for DNSSEC-validation of this zone.
Here's what happened.
1. The zone was signed originally using dnssec-policy which generated the initial keys:
```
01-Feb-2021 16:53:35.845 zoneload: info: managed-keys-zone: loaded serial 0
01-Feb-2021 16:53:35.845 zoneload: info: zone example.com/IN: loaded serial 1000
01-Feb-2021 16:53:35.845 general: notice: all zones loaded
01-Feb-2021 16:53:35.845 general: notice: running
01-Feb-2021 16:53:35.845 notify: info: zone example.com/IN: sending notifies (serial 1000)
01-Feb-2021 16:53:35.846 dnssec: info: zone example.com/IN: reconfiguring zone keys
01-Feb-2021 16:53:35.846 dnssec: info: keymgr: DNSKEY example.com/ECDSAP256SHA256/57955 (KSK) created for policy example_DNSSEC_DEFAULT
01-Feb-2021 16:53:35.846 dnssec: info: keymgr: DNSKEY example.com/ECDSAP256SHA256/32569 (ZSK) created for policy example_DNSSEC_DEFAULT
01-Feb-2021 16:53:35.847 dnssec: info: Fetching example.com/ECDSAP256SHA256/57955 (KSK) from key repository.
01-Feb-2021 16:53:35.847 dnssec: info: DNSKEY example.com/ECDSAP256SHA256/57955 (KSK) is now published
01-Feb-2021 16:53:35.847 dnssec: info: DNSKEY example.com/ECDSAP256SHA256/57955 (KSK) is now active
01-Feb-2021 16:53:35.847 dnssec: info: Fetching example.com/ECDSAP256SHA256/32569 (ZSK) from key repository.
01-Feb-2021 16:53:35.847 dnssec: info: DNSKEY example.com/ECDSAP256SHA256/32569 (ZSK) is now published
01-Feb-2021 16:53:35.847 dnssec: info: DNSKEY example.com/ECDSAP256SHA256/32569 (ZSK) is now active
01-Feb-2021 16:53:35.851 dnssec: info: zone example.com/IN: next key event: 03-Feb-2021 17:53:35.846
```
2. All was good, with the DS in the parent zone and the signatures being refreshed automatically, until there was a restart of named with the keys unaccessible (some directory changes, the ramifications of which were not fully understood, nor the bad outcome anticipated). This is what was logged:
The zone is loaded and initiates the notifies:
`18-Mar-2021 18:26:06.346 notify: info: zone example.com/IN: sending notifies (serial 1616023774)`
But then runs into trouble because it can't access the DNSSEC keys (which is interesting, because I don't think this is how named used to behave when loading a zone with RRSIGs from keys it doesn't have):
```
18-Mar-2021 18:26:06.346 dnssec: info: zone example.com/IN: reconfiguring zone keys
18-Mar-2021 18:26:06.347 general: warning: dns_dnssec_keylistfromrdataset: error reading Kexample.com.+013+32569.private: file not found
```
^^^^ Oh dear
`18-Mar-2021 18:26:06.347 general: warning: dns_dnssec_keylistfromrdataset: error reading Kexample.com.+013+57955.private: file not found`
^^^^ Also oh dear...
And this is what dnssec-policy decided to do about it. This made a small oops (RRSIG maintenance broken) into something far far worse. We end up with:
- an updated DNSKEY RRset whose signature from the old KSK can't be refreshed (so fails validation).
- a covering signature for the new RRset from the new KSK (which also fails validation because it's not in the parent zone as a signed DS record).
- named starts replacing zone RR RRSIGs with ones created from the new ZSK as the old ones expire (which is also bad, because the ZSK wasn't pre-published for long enough for the operators to be sure that it has reached all caches).
- and even if the zone operators were able to fix the missing DS in the parent as well as refresh the RRSIG covering the DNSKEY set with the old KSK too - there are still issues with the new ZSK-signed RRSIGs because the key hasn't been 'known' for long enough.
-->
```
18-Mar-2021 18:26:06.347 dnssec: info: keymgr: DNSKEY example.com/ECDSAP256SHA256/39037 (KSK) created for policy example_DNSSEC_DEFAULT
18-Mar-2021 18:26:06.348 dnssec: info: keymgr: DNSKEY example.com/ECDSAP256SHA256/27753 (ZSK) created for policy example_DNSSEC_DEFAULT
18-Mar-2021 18:26:06.354 dnssec: info: Fetching example.com/ECDSAP256SHA256/39037 (KSK) from key repository.
18-Mar-2021 18:26:06.354 dnssec: info: DNSKEY example.com/ECDSAP256SHA256/39037 (KSK) is now published
18-Mar-2021 18:26:06.354 dnssec: info: DNSKEY example.com/ECDSAP256SHA256/39037 (KSK) is now active
18-Mar-2021 18:26:06.354 dnssec: info: Fetching example.com/ECDSAP256SHA256/27753 (ZSK) from key repository.
18-Mar-2021 18:26:06.354 dnssec: info: DNSKEY example.com/ECDSAP256SHA256/27753 (ZSK) is now published
18-Mar-2021 18:26:06.354 dnssec: info: DNSKEY example.com/ECDSAP256SHA256/27753 (ZSK) is now active
18-Mar-2021 18:26:06.355 general: warning: dns_dnssec_findzonekeys2: error reading Kexample.com.+013+32569.private: file not found
```
And the DNSKEY RRset now has 4 keys instead of two:
- Original KSK ID 57955
- New KSK ID 39037
- Original ZSK ID 32569
- New ZSK ID 27753
This is a bad thing that dnssec-policy has done to the zone, in response to an 'oops' - one that is hard to get back from gracefully, as resolvers start to query and cache the zone content. Better would have been (IMHO) to have not rolled the keys and to have done something like:
- Log a lot of errors
- Maybe just not start named or not load this zone when starting?
- If doing a reconfig or reload, not load the zone (and also log a lot of errors)
- If this scenario is encountered (I'm imagining e.g. an HSM that has gone unavailable unexpectedly, or a file system that contained the private key files unmounting) dynamically, then also log a lot of errors.
I'm not sure if unloading the zone would be a good response or not (discuss?)
I think that removing the old RRSIGs and NSEC(3) chains from the zone would also be bad (I'm thinking about what used to happen before dnssec-policy when adopting a zone that has RRSIGs from the previous zone host, where we don't have the private key). But we should maybe also think about some of these other zone migration cases too, not just about accidental issues.May 2021 (9.11.32, 9.11.32-S1, 9.16.16, 9.16.16-S1, 9.17.13)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.org