ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2022-08-26T13:17:55Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3489CID 355779: Null pointer dereferences in lib/dns/tkey.c2022-08-26T13:17:55ZMichal NowakCID 355779: Null pointer dereferences in lib/dns/tkey.cCoverity Scan identified the following issue on `main`:
```
*** CID 355779: Null pointer dereferences (REVERSE_INULL)
/lib/dns/tkey.c: 997 in buildquery()
991 dns_message_puttempname(msg, &aname);
992 }
993 if (question...Coverity Scan identified the following issue on `main`:
```
*** CID 355779: Null pointer dereferences (REVERSE_INULL)
/lib/dns/tkey.c: 997 in buildquery()
991 dns_message_puttempname(msg, &aname);
992 }
993 if (question != NULL) {
994 dns_rdataset_disassociate(question);
995 dns_message_puttemprdataset(msg, &question);
996 }
>>> CID 355779: Null pointer dereferences (REVERSE_INULL)
>>> Null-checking "dynbuf" suggests that it may be null, but it has already been dereferenced on all paths leading to the check.
997 if (dynbuf != NULL) {
998 isc_buffer_free(&dynbuf);
999 }
1000 return (result);
1001 }
1002
```
5c8cb7cc3f13eb1d041bd6264c61b3d30707b4c5 might be the culprit. @aram can you have a look?September 2022 (9.16.33, 9.16.33-S1, 9.18.7, 9.19.5)Arаm SаrgsyаnArаm Sаrgsyаnhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3488ThreadSanitizer: data race lib/dns/adb.c:4319:19 in maybe_adjust_quota2022-09-06T09:02:13ZMichal NowakThreadSanitizer: data race lib/dns/adb.c:4319:19 in maybe_adjust_quotaJob [#2688640](https://gitlab.isc.org/isc-projects/bind9/-/jobs/2688640) failed for 81146953560723aeb2033cb19e423ac3d619ab30.
There are four TSAN reports in the failed job, three of them already reported as isc-projects/bind9#3424 and i...Job [#2688640](https://gitlab.isc.org/isc-projects/bind9/-/jobs/2688640) failed for 81146953560723aeb2033cb19e423ac3d619ab30.
There are four TSAN reports in the failed job, three of them already reported as isc-projects/bind9#3424 and isc-projects/bind9#3425.
The remaining one seems like a new thing, but also possibly a duplicate of either of the two above:
```
WARNING: ThreadSanitizer: data race
Write of size 8 at 0x000000000001 by thread T1 (mutexes: write M1):
#0 maybe_adjust_quota lib/dns/adb.c:4319:19 (BuildId: a361e9d59b9bacb0a373dff795784107085894b3)
#1 dns_adb_timeout lib/dns/adb.c:4416:2 (BuildId: a361e9d59b9bacb0a373dff795784107085894b3)
#2 update_edns_stats lib/dns/resolver.c:1260:3 (BuildId: a361e9d59b9bacb0a373dff795784107085894b3)
#3 fctx_cancelquery lib/dns/resolver.c:1322:4
#4 fctx_timeout lib/dns/resolver.c:4718:4 (BuildId: a361e9d59b9bacb0a373dff795784107085894b3)
#5 task_run lib/isc/task.c:851:5 (BuildId: e0d729256a5c7a436c61de3796656fc58ea302a0)
#6 isc_task_run lib/isc/task.c:944:10
#7 process_netievent lib/isc/netmgr/netmgr.c (BuildId: e0d729256a5c7a436c61de3796656fc58ea302a0)
#8 process_queue lib/isc/netmgr/netmgr.c:999:8 (BuildId: e0d729256a5c7a436c61de3796656fc58ea302a0)
#9 process_all_queues lib/isc/netmgr/netmgr.c:780:25 (BuildId: e0d729256a5c7a436c61de3796656fc58ea302a0)
#10 async_cb lib/isc/netmgr/netmgr.c:809:6
#11 uv__async_io /usr/src/libuv-v1.44.1/src/unix/async.c:163:5 (BuildId: 120c450d14885aa5308bc95c4ea77de2c2b1cc36)
#12 isc__trampoline_run lib/isc/trampoline.c:213:11 (BuildId: e0d729256a5c7a436c61de3796656fc58ea302a0)
Previous read of size 8 at 0x000000000001 by thread T2 (mutexes: write M3, write M3):
#0 dump_entry lib/dns/adb.c:3586:61 (BuildId: a361e9d59b9bacb0a373dff795784107085894b3)
#1 print_namehook_list lib/dns/adb.c:3678:3 (BuildId: a361e9d59b9bacb0a373dff795784107085894b3)
#2 dump_adb lib/dns/adb.c:3502:4
#3 dns_adb_dump lib/dns/adb.c:3417:2
#4 dumpdone bin/named/./server.c:11125:4 (BuildId: 3f0432fae76a976c190849cf408f82c1a0e9f07c)
#5 named_server_dumpdb bin/named/./server.c (BuildId: 3f0432fae76a976c190849cf408f82c1a0e9f07c)
#6 named_control_docommand bin/named/control.c:221:3 (BuildId: 3f0432fae76a976c190849cf408f82c1a0e9f07c)
#7 control_recvmessage bin/named/controlconf.c:474:13 (BuildId: 3f0432fae76a976c190849cf408f82c1a0e9f07c)
#8 task_run lib/isc/task.c:851:5 (BuildId: e0d729256a5c7a436c61de3796656fc58ea302a0)
#9 isc_task_run lib/isc/task.c:944:10
#10 process_netievent lib/isc/netmgr/netmgr.c (BuildId: e0d729256a5c7a436c61de3796656fc58ea302a0)
#11 process_queue lib/isc/netmgr/netmgr.c:999:8 (BuildId: e0d729256a5c7a436c61de3796656fc58ea302a0)
#12 process_all_queues lib/isc/netmgr/netmgr.c:780:25 (BuildId: e0d729256a5c7a436c61de3796656fc58ea302a0)
#13 async_cb lib/isc/netmgr/netmgr.c:809:6
#14 uv__async_io /usr/src/libuv-v1.44.1/src/unix/async.c:163:5 (BuildId: 120c450d14885aa5308bc95c4ea77de2c2b1cc36)
#15 isc__trampoline_run lib/isc/trampoline.c:213:11 (BuildId: e0d729256a5c7a436c61de3796656fc58ea302a0)
Location is heap block of size 305 at 0x000000000018 allocated by thread T3:
#0 malloc <null> (BuildId: 3f0432fae76a976c190849cf408f82c1a0e9f07c)
#1 default_memalloc lib/isc/mem.c:715:8 (BuildId: e0d729256a5c7a436c61de3796656fc58ea302a0)
#2 mem_get lib/isc/mem.c:624:8 (BuildId: e0d729256a5c7a436c61de3796656fc58ea302a0)
#3 mem_allocateunlocked lib/isc/mem.c:1289:8
#4 isc___mem_allocate lib/isc/mem.c:1309:7
#5 isc__mem_allocate lib/isc/mem.c:2394:10 (BuildId: e0d729256a5c7a436c61de3796656fc58ea302a0)
#6 isc___mem_get lib/isc/mem.c:1059:11 (BuildId: e0d729256a5c7a436c61de3796656fc58ea302a0)
#7 isc__mem_get lib/isc/mem.c:2373:10 (BuildId: e0d729256a5c7a436c61de3796656fc58ea302a0)
#8 new_adbentry lib/dns/adb.c:1863:6 (BuildId: a361e9d59b9bacb0a373dff795784107085894b3)
#9 import_rdataset lib/dns/adb.c:969:12 (BuildId: a361e9d59b9bacb0a373dff795784107085894b3)
#10 fetch_callback lib/dns/adb.c:4024:11 (BuildId: a361e9d59b9bacb0a373dff795784107085894b3)
#11 task_run lib/isc/task.c:851:5 (BuildId: e0d729256a5c7a436c61de3796656fc58ea302a0)
#12 isc_task_run lib/isc/task.c:944:10
#13 process_netievent lib/isc/netmgr/netmgr.c (BuildId: e0d729256a5c7a436c61de3796656fc58ea302a0)
#14 process_queue lib/isc/netmgr/netmgr.c:999:8 (BuildId: e0d729256a5c7a436c61de3796656fc58ea302a0)
#15 process_all_queues lib/isc/netmgr/netmgr.c:780:25 (BuildId: e0d729256a5c7a436c61de3796656fc58ea302a0)
#16 async_cb lib/isc/netmgr/netmgr.c:809:6
#17 uv__async_io /usr/src/libuv-v1.44.1/src/unix/async.c:163:5 (BuildId: 120c450d14885aa5308bc95c4ea77de2c2b1cc36)
#18 isc__trampoline_run lib/isc/trampoline.c:213:11 (BuildId: e0d729256a5c7a436c61de3796656fc58ea302a0)
Mutex M3 (0x000000000028) created at:
#0 pthread_mutex_init <null> (BuildId: 3f0432fae76a976c190849cf408f82c1a0e9f07c)
#1 isc__mutex_init lib/isc/pthreads/mutex.c:290:8 (BuildId: e0d729256a5c7a436c61de3796656fc58ea302a0)
#2 isc_mutexblock_init lib/isc/mutexblock.c:24:3 (BuildId: e0d729256a5c7a436c61de3796656fc58ea302a0)
#3 dns_adb_create lib/dns/adb.c:2686:2 (BuildId: a361e9d59b9bacb0a373dff795784107085894b3)
#4 dns_view_createresolver lib/dns/view.c:830:11 (BuildId: a361e9d59b9bacb0a373dff795784107085894b3)
#5 configure_view bin/named/./server.c:4675:2 (BuildId: 3f0432fae76a976c190849cf408f82c1a0e9f07c)
#6 load_configuration bin/named/./server.c:9105:3 (BuildId: 3f0432fae76a976c190849cf408f82c1a0e9f07c)
#7 run_server bin/named/./server.c:9815:2 (BuildId: 3f0432fae76a976c190849cf408f82c1a0e9f07c)
#8 task_run lib/isc/task.c:851:5 (BuildId: e0d729256a5c7a436c61de3796656fc58ea302a0)
#9 isc_task_run lib/isc/task.c:944:10
#10 process_netievent lib/isc/netmgr/netmgr.c (BuildId: e0d729256a5c7a436c61de3796656fc58ea302a0)
#11 process_queue lib/isc/netmgr/netmgr.c:999:8 (BuildId: e0d729256a5c7a436c61de3796656fc58ea302a0)
#12 process_all_queues lib/isc/netmgr/netmgr.c:780:25 (BuildId: e0d729256a5c7a436c61de3796656fc58ea302a0)
#13 async_cb lib/isc/netmgr/netmgr.c:809:6
#14 uv__async_io /usr/src/libuv-v1.44.1/src/unix/async.c:163:5 (BuildId: 120c450d14885aa5308bc95c4ea77de2c2b1cc36)
#15 isc__trampoline_run lib/isc/trampoline.c:213:11 (BuildId: e0d729256a5c7a436c61de3796656fc58ea302a0)
Mutex M3 (0x000000000037) created at:
#0 pthread_mutex_init <null> (BuildId: 3f0432fae76a976c190849cf408f82c1a0e9f07c)
#1 isc__mutex_init lib/isc/pthreads/mutex.c:290:8 (BuildId: e0d729256a5c7a436c61de3796656fc58ea302a0)
#2 dns_adb_create lib/dns/adb.c:2636:2 (BuildId: a361e9d59b9bacb0a373dff795784107085894b3)
#3 dns_view_createresolver lib/dns/view.c:830:11 (BuildId: a361e9d59b9bacb0a373dff795784107085894b3)
#4 configure_view bin/named/./server.c:4675:2 (BuildId: 3f0432fae76a976c190849cf408f82c1a0e9f07c)
#5 load_configuration bin/named/./server.c:9105:3 (BuildId: 3f0432fae76a976c190849cf408f82c1a0e9f07c)
#6 run_server bin/named/./server.c:9815:2 (BuildId: 3f0432fae76a976c190849cf408f82c1a0e9f07c)
#7 task_run lib/isc/task.c:851:5 (BuildId: e0d729256a5c7a436c61de3796656fc58ea302a0)
#8 isc_task_run lib/isc/task.c:944:10
#9 process_netievent lib/isc/netmgr/netmgr.c (BuildId: e0d729256a5c7a436c61de3796656fc58ea302a0)
#10 process_queue lib/isc/netmgr/netmgr.c:999:8 (BuildId: e0d729256a5c7a436c61de3796656fc58ea302a0)
#11 process_all_queues lib/isc/netmgr/netmgr.c:780:25 (BuildId: e0d729256a5c7a436c61de3796656fc58ea302a0)
#12 async_cb lib/isc/netmgr/netmgr.c:809:6
#13 uv__async_io /usr/src/libuv-v1.44.1/src/unix/async.c:163:5 (BuildId: 120c450d14885aa5308bc95c4ea77de2c2b1cc36)
#14 isc__trampoline_run lib/isc/trampoline.c:213:11 (BuildId: e0d729256a5c7a436c61de3796656fc58ea302a0)
Mutex M3 (0x000000000039) created at:
#0 pthread_mutex_init <null> (BuildId: 3f0432fae76a976c190849cf408f82c1a0e9f07c)
#1 isc__mutex_init lib/isc/pthreads/mutex.c:290:8 (BuildId: e0d729256a5c7a436c61de3796656fc58ea302a0)
#2 isc_mutexblock_init lib/isc/mutexblock.c:24:3 (BuildId: e0d729256a5c7a436c61de3796656fc58ea302a0)
#3 dns_adb_create lib/dns/adb.c:2670:2 (BuildId: a361e9d59b9bacb0a373dff795784107085894b3)
#4 dns_view_createresolver lib/dns/view.c:830:11 (BuildId: a361e9d59b9bacb0a373dff795784107085894b3)
#5 configure_view bin/named/./server.c:4675:2 (BuildId: 3f0432fae76a976c190849cf408f82c1a0e9f07c)
#6 load_configuration bin/named/./server.c:9105:3 (BuildId: 3f0432fae76a976c190849cf408f82c1a0e9f07c)
#7 run_server bin/named/./server.c:9815:2 (BuildId: 3f0432fae76a976c190849cf408f82c1a0e9f07c)
#8 task_run lib/isc/task.c:851:5 (BuildId: e0d729256a5c7a436c61de3796656fc58ea302a0)
#9 isc_task_run lib/isc/task.c:944:10
#10 process_netievent lib/isc/netmgr/netmgr.c (BuildId: e0d729256a5c7a436c61de3796656fc58ea302a0)
#11 process_queue lib/isc/netmgr/netmgr.c:999:8 (BuildId: e0d729256a5c7a436c61de3796656fc58ea302a0)
#12 process_all_queues lib/isc/netmgr/netmgr.c:780:25 (BuildId: e0d729256a5c7a436c61de3796656fc58ea302a0)
#13 async_cb lib/isc/netmgr/netmgr.c:809:6
#14 uv__async_io /usr/src/libuv-v1.44.1/src/unix/async.c:163:5 (BuildId: 120c450d14885aa5308bc95c4ea77de2c2b1cc36)
#15 isc__trampoline_run lib/isc/trampoline.c:213:11 (BuildId: e0d729256a5c7a436c61de3796656fc58ea302a0)
Thread T2 (running) created by main thread at:
#0 pthread_create <null> (BuildId: 3f0432fae76a976c190849cf408f82c1a0e9f07c)
#1 isc_thread_create lib/isc/pthreads/thread.c:81:8 (BuildId: e0d729256a5c7a436c61de3796656fc58ea302a0)
#2 isc__netmgr_create lib/isc/netmgr/netmgr.c:345:3 (BuildId: e0d729256a5c7a436c61de3796656fc58ea302a0)
#3 isc_managers_create lib/isc/managers.c:28:2 (BuildId: e0d729256a5c7a436c61de3796656fc58ea302a0)
#4 create_managers bin/named/./main.c:931:11 (BuildId: 3f0432fae76a976c190849cf408f82c1a0e9f07c)
#5 setup bin/named/./main.c:1256:11
#6 main bin/named/./main.c:1564:2
Thread T2 (running) created by main thread at:
#0 pthread_create <null> (BuildId: 3f0432fae76a976c190849cf408f82c1a0e9f07c)
#1 isc_thread_create lib/isc/pthreads/thread.c:81:8 (BuildId: e0d729256a5c7a436c61de3796656fc58ea302a0)
#2 isc__netmgr_create lib/isc/netmgr/netmgr.c:345:3 (BuildId: e0d729256a5c7a436c61de3796656fc58ea302a0)
#3 isc_managers_create lib/isc/managers.c:28:2 (BuildId: e0d729256a5c7a436c61de3796656fc58ea302a0)
#4 create_managers bin/named/./main.c:931:11 (BuildId: 3f0432fae76a976c190849cf408f82c1a0e9f07c)
#5 setup bin/named/./main.c:1256:11
#6 main bin/named/./main.c:1564:2
Thread T3 (running) created by main thread at:
#0 pthread_create <null> (BuildId: 3f0432fae76a976c190849cf408f82c1a0e9f07c)
#1 isc_thread_create lib/isc/pthreads/thread.c:81:8 (BuildId: e0d729256a5c7a436c61de3796656fc58ea302a0)
#2 isc__netmgr_create lib/isc/netmgr/netmgr.c:345:3 (BuildId: e0d729256a5c7a436c61de3796656fc58ea302a0)
#3 isc_managers_create lib/isc/managers.c:28:2 (BuildId: e0d729256a5c7a436c61de3796656fc58ea302a0)
#4 create_managers bin/named/./main.c:931:11 (BuildId: 3f0432fae76a976c190849cf408f82c1a0e9f07c)
#5 setup bin/named/./main.c:1256:11
#6 main bin/named/./main.c:1564:2
SUMMARY: ThreadSanitizer: data race lib/dns/adb.c:4319:19 in maybe_adjust_quota
```September 2022 (9.16.33, 9.16.33-S1, 9.18.7, 9.19.5)Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/3487[CVE-2022-38177] [CVE-2022-38178] Memory leaks in ECDSA and EdDSA DNSSEC veri...2022-12-21T15:44:32ZMark Andrews[CVE-2022-38177] [CVE-2022-38178] Memory leaks in ECDSA and EdDSA DNSSEC verification code### CVE-specific actions
- [x] Assign a CVE identifier: CVE-2022-38177, CVE-2022-38178
- [x] Determine CVSS score: 7.5 (6.8): CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H/E:P/RL:T/RC:C
- [x] Determine the range of BIND versions af...### CVE-specific actions
- [x] Assign a CVE identifier: CVE-2022-38177, CVE-2022-38178
- [x] Determine CVSS score: 7.5 (6.8): CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H/E:P/RL:T/RC:C
- [x] Determine the range of BIND versions affected: ECDSA: 9.16.0 - 9.16.32 (including -S), EDDSA: 9.16.0 - 9.16.32 (including -S), 9.18.0 - 9.18.6
- [x] Determine whether workarounds for the problem exists: Yes: disable the EC algorithms in `named.conf`
- [x] Create a draft of the security advisory and put the information above in there
- [x] Prepare a detailed description of the problem which should include the following by default:
- instructions for reproducing the problem
- explanation of code flow which triggers the problem
- [x] Prepare a private merge request containing the following items in separate commits:
- 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, 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 maintaned 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
**Note:** See https://gitlab.isc.org/isc-private/bind9/-/issues/54
### 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
### Post-disclosure actions
- [x] Merge a regression test reproducing the bug into all affected (and still maintained) BIND branches
### Incident tracking
https://gitlab.isc.org/isc-private/bind9/-/issues/54
# Report: Memory leaks in ECDSA and EDDSA verify methods
!6648 (into `v9_16`, now deleted) discovered a memory leak when running `mkey` in the ECDSA verify method.
```
==29284==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 240 byte(s) in 3 object(s) allocated from:
#0 0x56450472021e in malloc (/builds/isc-projects/bind9/bin/named/.libs/named+0x18a21e) (BuildId: 521441dd3d6cde644a836b815e28af52a7ef1343)
#1 0x7f24e3931349 in CRYPTO_zalloc (/usr/lib/x86_64-linux-gnu/libcrypto.so.1.1+0x195349) (BuildId: 6bc8b0545e8b77a3c250fa8462431979d25036fe)
Indirect leak of 3168 byte(s) in 84 object(s) allocated from:
#0 0x56450472021e in malloc (/builds/isc-projects/bind9/bin/named/.libs/named+0x18a21e) (BuildId: 521441dd3d6cde644a836b815e28af52a7ef1343)
#1 0x7f24e3931349 in CRYPTO_zalloc (/usr/lib/x86_64-linux-gnu/libcrypto.so.1.1+0x195349) (BuildId: 6bc8b0545e8b77a3c250fa8462431979d25036fe)
Indirect leak of 624 byte(s) in 6 object(s) allocated from:
#0 0x56450472021e in malloc (/builds/isc-projects/bind9/bin/named/.libs/named+0x18a21e) (BuildId: 521441dd3d6cde644a836b815e28af52a7ef1343)
#1 0x7f24e386f157 in BN_MONT_CTX_new (/usr/lib/x86_64-linux-gnu/libcrypto.so.1.1+0xd3157) (BuildId: 6bc8b0545e8b77a3c250fa8462431979d25036fe)
Indirect leak of 360 byte(s) in 12 object(s) allocated from:
#0 0x56450472021e in malloc (/builds/isc-projects/bind9/bin/named/.libs/named+0x18a21e) (BuildId: 521441dd3d6cde644a836b815e28af52a7ef1343)
#1 0x7f24e3931349 in CRYPTO_zalloc (/usr/lib/x86_64-linux-gnu/libcrypto.so.1.1+0x195349) (BuildId: 6bc8b0545e8b77a3c250fa8462431979d25036fe)
#2 0xbf900568665c8def (<unknown module>)
Indirect leak of 60 byte(s) in 3 object(s) allocated from:
#0 0x56450472021e in malloc (/builds/isc-projects/bind9/bin/named/.libs/named+0x18a21e) (BuildId: 521441dd3d6cde644a836b815e28af52a7ef1343)
#1 0x7f24e38bc79f in EC_GROUP_set_seed (/usr/lib/x86_64-linux-gnu/libcrypto.so.1.1+0x12079f) (BuildId: 6bc8b0545e8b77a3c250fa8462431979d25036fe)
SUMMARY: AddressSanitizer: 4452 byte(s) leaked in 108 allocation(s).
```
Inspecting `opensslecdsa_link.c` showed a memory leak in the verify method (a05a7e96). d4eb6e0a57a7eeb42328ff66865fa66688603c17 addressed this in `9.18` and `main`.
Inspection of `openssleddsa_link.c` showed a similar issue (81146953).
### CVSS Scoring
CVSS 7.5 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
- DNSSEC validation is enabled by default in later versions so there is no operator intervention
- I've left scope as unchanged though memory leaks could potentially affect other processes, changed would raise this to 8.6.
- I've left availability as high, low would reduce this to 5.3 (scope changed 5.8).
### Vulnerability Details
By default BIND is configured to do DNSSEC validation. When presented with a response that has a malformed EC (`ECDSAP256SHA256` and `ECDSAP384SHA384`) or ED (`ED25519` and `ED448`) signature, BIND will leak a small amount of memory. To be more specific, the malformed signature must have a wrong signature length.
This can be done by spoofing a response, or by setting up an authoritative zone that will return such a malformed response and query for a domain within that zone.
### Mitigation
Disable the EC (`ECDSAP256SHA256` and `ECDSAP384SHA384`) and ED (`ED25519` and `ED448`) algorithms in `named.conf` with `disable-algorithms. This will however treat zones signed with these algorithms as insecure.September 2022 (9.16.33, 9.16.33-S1, 9.18.7, 9.19.5)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/3486Figure out that kasp changes from NSEC only DNSKEY zone to NSEC32022-09-06T09:04:13ZMatthijs Mekkingmatthijs@isc.orgFigure out that kasp changes from NSEC only DNSKEY zone to NSEC3A story:
> I was too quick switching to NSEC3, which is incompatible with the old key. Switching back to NSEC allowed the
> rollover to complete. Still, shouldn't BIND have been able to figure this out on its own? It kept using NSEC
> b...A story:
> I was too quick switching to NSEC3, which is incompatible with the old key. Switching back to NSEC allowed the
> rollover to complete. Still, shouldn't BIND have been able to figure this out on its own? It kept using NSEC
> because of the incompatible key, and it kept the incompatible key needed to verify the NSEC records.
I realized we have code to detect such an erroneous state, but we can use that code also to fallback using NSEC if there are offending DNSKEYs in the zone.
So yes, I think BIND is capable of figuring this out.September 2022 (9.16.33, 9.16.33-S1, 9.18.7, 9.19.5)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/3485dig: IDNA2003 names raises error when queried as ACE2022-09-06T09:37:36ZRomuald Brunetdig: IDNA2003 names raises error when queried as ACE### Description
While working on a few IDNA domains I just found out that dig only supports IDNA2008
There is no issue with not supporting IDNA 2003, however aborting when querying for an ASCII domain seems problematic to me
(especiall...### Description
While working on a few IDNA domains I just found out that dig only supports IDNA2008
There is no issue with not supporting IDNA 2003, however aborting when querying for an ASCII domain seems problematic to me
(especially for actual, valid domains)
For example, the domain 🥝.st (translated to xn--zr9h.st), which exists and is currently working in browsers
```console
$ dig +short A xn--zr9h.st
dig: 'xn--zr9h.st' is not a legal IDN name (Unknown error), use +noidnin
$ dig +short A xn--zr9h.st +noidnin
dig: 'xn--zr9h.st.' is not a legal IDNA2008 name (string contains a disallowed character), use +noidnout
$ dig +short A xn--zr9h.st +noidnin +noidnout
x.y.z.38
```
### Request
What I would like in that case, is dig only raising a warning an skipping IDNA conversion (since I'm explicitly querying the ASCII version)
### Links / references
Related to #26 (probably)September 2022 (9.16.33, 9.16.33-S1, 9.18.7, 9.19.5)Tony FinchTony Finchhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3483"INSIST(s >= size);" assertion failed in mem_putstats()2022-09-06T08:28:58ZMichał Kępień"INSIST(s >= size);" assertion failed in mem_putstats()The following crash [happened][1] when the `tcp` test was run on an
Alpine 3.16 Docker image:
```
D:tcp:Core was generated by `/builds/isc-projects/bind9/bin/named/.libs/lt-named -D tcp-ns1 -X named.lock -m'.
D:tcp:Program terminated w...The following crash [happened][1] when the `tcp` test was run on an
Alpine 3.16 Docker image:
```
D:tcp:Core was generated by `/builds/isc-projects/bind9/bin/named/.libs/lt-named -D tcp-ns1 -X named.lock -m'.
D:tcp:Program terminated with signal SIGABRT, Aborted.
D:tcp:#0 __restore_sigs (set=set@entry=0x7f6d912bb080) at ./arch/x86_64/syscall_arch.h:40
D:tcp:[Current thread is 1 (LWP 26680)]
D:tcp:#0 __restore_sigs (set=set@entry=0x7f6d912bb080) at ./arch/x86_64/syscall_arch.h:40
D:tcp:#1 0x00007f6d93d32561 in raise (sig=sig@entry=6) at src/signal/raise.c:11
D:tcp:#2 0x00007f6d93d08f49 in abort () at src/exit/abort.c:11
D:tcp:#3 0x0000557481282cdc in assertion_failed (file=<optimized out>, line=<optimized out>, type=<optimized out>, cond=0x7f6d937ce5f5 "s >= size") at main.c:237
D:tcp:#4 0x00007f6d9378f8d8 in isc_assertion_failed (file=file@entry=0x7f6d937ce5e7 "mem.c", line=line@entry=422, type=type@entry=isc_assertiontype_insist, cond=cond@entry=0x7f6d937ce5f5 "s >= size") at assertions.c:49
D:tcp:#5 0x00007f6d937a0b66 in mem_putstats (ctx=ctx@entry=0x7f6d8fc12000, ptr=ptr@entry=0x7f6c55248a80, size=size@entry=65535) at mem.c:422
D:tcp:#6 0x00007f6d937a1924 in isc__mem_put (ctx=0x7f6d8fc12000, ptr=0x7f6c55248a80, size=size@entry=65535, alignment=alignment@entry=0, file=file@entry=0x7f6d9351c014 "client.c", line=line@entry=1631) at mem.c:778
D:tcp:#7 0x00007f6d934edbdf in ns__client_reset_cb (client0=0x7f6c55184c00) at client.c:1631
D:tcp:#8 0x00007f6d937795b9 in nmhandle_detach_cb (handlep=handlep@entry=0x7f6c6b524db8) at netmgr/netmgr.c:1802
D:tcp:#9 0x00007f6d9377be57 in isc__nm_async_detach (ev0=0x7f6c6b524d80, worker=0x7f6d9244bf80) at netmgr/netmgr.c:2829
D:tcp:#10 process_netievent (worker=worker@entry=0x7f6d9244bf80, ievent=0x7f6c6b524d80) at netmgr/netmgr.c:947
D:tcp:#11 0x00007f6d9377c13e in process_queue (worker=worker@entry=0x7f6d9244bf80, type=type@entry=NETIEVENT_PRIORITY) at netmgr/netmgr.c:979
D:tcp:#12 0x00007f6d9377ced2 in process_all_queues (worker=0x7f6d9244bf80) at netmgr/netmgr.c:749
D:tcp:#13 async_cb (handle=0x7f6d9244c2e0) at netmgr/netmgr.c:778
D:tcp:#14 0x00007f6d93070b59 in ?? () from /usr/lib/libuv.so.1
D:tcp:#15 0x00007f6d93080834 in uv.io_poll () from /usr/lib/libuv.so.1
D:tcp:#16 0x00007f6d9307113b in uv_run () from /usr/lib/libuv.so.1
D:tcp:#17 0x00007f6d9377c509 in nm_thread (worker0=0x7f6d9244bf80) at netmgr/netmgr.c:687
D:tcp:#18 0x00007f6d937b97c0 in isc__trampoline_run (arg=0x7f6d91fd9ca0) at trampoline.c:189
D:tcp:#19 0x00007f6d93d3f1f5 in start (p=0x7f6d912bef48) at src/thread/pthread_create.c:203
D:tcp:#20 0x00007f6d93d41470 in __clone () at src/thread/x86_64/clone.s:22
```
This corresponds to the following code location:
```c
411 /*!
412 * Update internal counters after a memory put.
413 */
414 static void
415 mem_putstats(isc_mem_t *ctx, void *ptr, size_t size) {
416 struct stats *stats = stats_bucket(ctx, size);
417 uint_fast32_t s, g;
418
419 UNUSED(ptr);
420
421 s = atomic_fetch_sub_release(&ctx->inuse, size);
422 >>> INSIST(s >= size);
423
424 g = atomic_fetch_sub_release(&stats->gets, 1);
425 INSIST(g >= 1);
426
427 decrement_malloced(ctx, size);
428 }
```
Failing this assertion seemingly means that there is less tracked memory
in use than the `size` of the allocation that just got released.
However, knowing that the particular `tcp` check that triggers this
crash intentionally allocates a lot of memory, I believe this is a case
of integer truncation:
```console
$ cat test.c
#include <stdio.h>
#include <stdatomic.h>
int main(void) {
atomic_size_t inuse = 1L << 33;
size_t size = 1L << 32;
atomic_uint_fast32_t s;
printf("(before) inuse=%lu\n", atomic_load(&inuse));
printf(" size=%lu\n", size);
s = atomic_fetch_sub(&inuse, size);
printf("(after) inuse=%lu\n", atomic_load(&inuse));
printf(" s=%u\n", s);
return 0;
}
$ gcc -o test -Wall -Wextra -pedantic test.c
$ ./test
(before) inuse=8589934592
size=4294967296
(after) inuse=4294967296
s=0
```
Since I do not recall seeing this crash before, I assume that
`ctx->inuse` in this particular job must have hit a particularly small
value in its lower 32 bits.
I believe this issue has only just been introduced, by !5518.
AFAICT, all it takes to fix this is to make `s` in `mem_putstats()` an
`atomic_size_t`.
I do not think exploiting this would be easy to control, but I am making
this issue confidential for now since a crash is involved.
[1]: https://gitlab.isc.org/isc-projects/bind9/-/jobs/2682061September 2022 (9.16.33, 9.16.33-S1, 9.18.7, 9.19.5)Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/3479contrib/dlz/modules/{mysql,mysqldyn} sets LDAP_LIBS instead of MYSQL_LIBS2022-08-26T09:07:43ZAndreas Stiegercontrib/dlz/modules/{mysql,mysqldyn} sets LDAP_LIBS instead of MYSQL_LIBS### Summary
From https://gitlab.isc.org/isc-projects/bind9/-/commit/67f76b126900d313b343f563353f8237a6a264d2
and https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/5427/diffs
In `contrib/dlz/modules/{mysql,mysqldyn}`. Instead o...### Summary
From https://gitlab.isc.org/isc-projects/bind9/-/commit/67f76b126900d313b343f563353f8237a6a264d2
and https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/5427/diffs
In `contrib/dlz/modules/{mysql,mysqldyn}`. Instead of
`LDAP_LIBS=$(shell mysql_config --libs)` you probably means `MYSQL_LIBS [...]`
### BIND version used
9.18.5 (and master)
### Steps to reproduce
n/a, obvious fix (community user reported no bindings to `libmariadb`)
### What is the current *bug* behavior?
mysql bindings not generated
### What is the expected *correct* behavior?
mysql binding generated
### Relevant configuration files
n/a, obvious fix
### Relevant logs and/or screenshots
https://bugzilla.opensuse.org/show_bug.cgi?id=1202149
### Possible fixes
````
- LDAP_LIBS=$(shell mysql_config --libs)
+ MYSQL_LIBS=$(shell mysql_config --libs)
````September 2022 (9.16.33, 9.16.33-S1, 9.18.7, 9.19.5)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/3478dig +nssearch crashes for the root zone2022-08-26T09:07:43ZArаm Sаrgsyаndig +nssearch crashes for the root zone`dig +nssearch .` command crashes, as discovered and reported by Thomas Amgarten in [this comment](https://gitlab.isc.org/isc-projects/bind9/-/issues/3474#note_305037).
This is a lookup reference counting bug, happening when `dig` sees ...`dig +nssearch .` command crashes, as discovered and reported by Thomas Amgarten in [this comment](https://gitlab.isc.org/isc-projects/bind9/-/issues/3474#note_305037).
This is a lookup reference counting bug, happening when `dig` sees a bad cookie in one of the queries running in parallel, and re-queues the lookup.
This isn't strictly related to the root zone, but the root zone has quite a few name servers, which increases the chances of encountering a `;; BADCOOKIE, retrying.` situation.
I'm preparing an MR with a fix and a more detailed description of the bug.September 2022 (9.16.33, 9.16.33-S1, 9.18.7, 9.19.5)Arаm SаrgsyаnArаm Sаrgsyаnhttps://gitlab.isc.org/isc-projects/stork/-/issues/827Display DHCP options in the host reservations view2022-08-19T12:56:30ZMarcin SiodelskiDisplay DHCP options in the host reservations viewThe host reservation view only shows IP addresses and DHCP identifiers. It should also display DHCP options associated with the host reservation. It is an important step on our way to implement host reservation updates. A user must first...The host reservation view only shows IP addresses and DHCP identifiers. It should also display DHCP options associated with the host reservation. It is an important step on our way to implement host reservation updates. A user must first examine/see the options before they decide on updating the reservation.1.6Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/stork/-/issues/825Encounter 404 when accessing isc-stork-server via port 80802022-09-02T19:26:18ZChee-Yang, ChauEncounter 404 when accessing isc-stork-server via port 8080I am using Ubuntu 22.04:
```
# cat /etc/os-release
PRETTY_NAME="Ubuntu 22.04 LTS"
NAME="Ubuntu"
VERSION_ID="22.04"
VERSION="22.04 LTS (Jammy Jellyfish)"
VERSION_CODENAME=jammy
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/"
...I am using Ubuntu 22.04:
```
# cat /etc/os-release
PRETTY_NAME="Ubuntu 22.04 LTS"
NAME="Ubuntu"
VERSION_ID="22.04"
VERSION="22.04 LTS (Jammy Jellyfish)"
VERSION_CODENAME=jammy
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
UBUNTU_CODENAME=jammy
```
I follow the [installation](https://stork.readthedocs.io/en/v1.5.0/install.html#installing-from-packages) step to setup stork service.
Here is the stork env file:
```
# cat /etc/stork/server.env
STORK_DATABASE_HOST=localhost
STORK_DATABASE_PORT=5432
STORK_DATABASE_NAME=stork
STORK_DATABASE_USER_NAME=stork
STORK_DATABASE_PASSWORD=password
```
The stork service also listen to port 8080:
```
# ss -nlt
State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
LISTEN 0 4096 127.0.0.53%lo:53 0.0.0.0:*
LISTEN 0 128 0.0.0.0:22 0.0.0.0:*
LISTEN 0 244 127.0.0.1:5432 0.0.0.0:*
LISTEN 0 4096 127.0.0.1:8000 0.0.0.0:*
LISTEN 0 4096 *:8080 *:*
LISTEN 0 128 [::]:22 [::]:*
```
The kea dhcp service is also active:
```
/# systemctl status isc-kea-dhcp4-server
● isc-kea-dhcp4-server.service - Kea IPv4 DHCP daemon
Loaded: loaded (/lib/systemd/system/isc-kea-dhcp4-server.service; enabled; vendor preset: enabled)
Active: active (running) since Fri 2022-07-29 09:49:53 UTC; 47min ago
Docs: man:kea-dhcp4(8)
Main PID: 661 (kea-dhcp4)
Tasks: 5 (limit: 3344)
Memory: 10.5M
CPU: 238ms
CGroup: /system.slice/isc-kea-dhcp4-server.service
└─661 /usr/sbin/kea-dhcp4 -c /etc/kea/kea-dhcp4.conf
```
But I receive 404 error when trying to access the service:
```
# curl -I http://localhost:8080/
HTTP/1.1 404 Not Found
Content-Type: text/plain; charset=utf-8
X-Content-Type-Options: nosniff
Date: Fri, 29 Jul 2022 10:30:56 GMT
Content-Length: 19
```
I don't have isc-stork-agent service setup yet.
Is there any configuration I miss?1.6Slawek FigielSlawek Figielhttps://gitlab.isc.org/isc-projects/stork/-/issues/824stork-demo.sh doesn't work on macOS2022-08-17T15:06:56ZMarcin Siodelskistork-demo.sh doesn't work on macOSI get the following error on macOS when I try to run `stork-demo.sh`:
```
./stork-demo.sh -h
getopt: illegal option -- n
```I get the following error on macOS when I try to run `stork-demo.sh`:
```
./stork-demo.sh -h
getopt: illegal option -- n
```1.6Slawek FigielSlawek Figielhttps://gitlab.isc.org/isc-projects/stork/-/issues/822System tests fails - missing Kea dependency2022-08-09T07:45:25ZSlawek FigielSystem tests fails - missing Kea dependencyStork system tests start failing due to missing Kea dependency:
```
#7 3.451 The following packages have unmet dependencies:
#7 3.490 isc-kea-ctrl-agent : Depends: python3-isc-kea-connector (= 2.0.2-isc20220227221539) but 2.0.3-isc2022...Stork system tests start failing due to missing Kea dependency:
```
#7 3.451 The following packages have unmet dependencies:
#7 3.490 isc-kea-ctrl-agent : Depends: python3-isc-kea-connector (= 2.0.2-isc20220227221539) but 2.0.3-isc20220725151155 is to be installed
#7 3.498 E: Unable to correct problems, you have held broken packages.
```
Command:
```
wget -q -O- https://dl.cloudsmith.io/${KEA_REPO}/cfg/setup/bash.deb.sh | bash \
&& apt-get update \
&& apt-get install \
--no-install-recommends \
-y \
isc-kea-ctrl-agent=${KEA_VER} \
isc-kea-dhcp4-server=${KEA_VER} \
isc-kea-dhcp6-server=${KEA_VER} \
isc-kea-admin=${KEA_VER} \
isc-kea-common=${KEA_VER}
```
for environment variables:
```
KEA_REPO=public/isc/kea-2-0
KEA_VER=2.0.2-isc20220227221539
```1.6Slawek FigielSlawek Figielhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3467dns_rdatalist_tordataset can not fail update prototype to return void2022-09-06T08:25:45ZMark Andrewsdns_rdatalist_tordataset can not fail update prototype to return voidUpdate prototype and cleanup unnecessary error handling.
Repeat for any calling functions that subsequently cannot fail.Update prototype and cleanup unnecessary error handling.
Repeat for any calling functions that subsequently cannot fail.September 2022 (9.16.33, 9.16.33-S1, 9.18.7, 9.19.5)Arаm SаrgsyаnArаm Sаrgsyаnhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3463Empty JSON in POST request causes connection die in BIND >= 9.182022-08-26T13:17:56ZSlawek FigielEmpty JSON in POST request causes connection die in BIND >= 9.18### Summary
We send an HTTP request to the BIND9 statistics endpoint (`/json/v1`). The request uses the POST method and contains empty JSON (`{}`) in the body. We re-use the HTTP connection between requests.
The problem starts occurrin...### Summary
We send an HTTP request to the BIND9 statistics endpoint (`/json/v1`). The request uses the POST method and contains empty JSON (`{}`) in the body. We re-use the HTTP connection between requests.
The problem starts occurring from the BIND 9.18 version. Every second request is refused. In previous BIND9 versions (tested on 9.16 and 9.11) worked well.
An external user initially reported the issue in [the Stork repository](https://gitlab.isc.org/isc-projects/stork/-/issues/798).
### BIND version used
We use BIND 9.18 inside [the official Docker container](https://hub.docker.com/r/internetsystemsconsortium/bind9).
### Steps to reproduce
The issue isn't related to the Stork code and can be reproduced using `curl`:
`curl -v -d '{}' -o/dev/null http://127.0.0.1:80/json/v1 -o/dev/null http://127.0.0.1:80/json/v1`
This command sends two requests to the statistics endpoint, re-using the same connection. The request body is an empty JSON. It implies the POST method. The request passes and returns HTTP 200 OK status. The second causes the connection to die. The `curl` recreates the connection and retry that finishes with success.
### What is the current *bug* behavior?
Every second request to BIND9 fails.
### What is the expected *correct* behavior?
BIND9 should accept every request as in the previous versions, or the documentation should contain a definition of the valid request.
### Relevant configuration files
`named.conf` content:
```
include "/etc/bind/rndc.key";
include "/etc/bind/named.conf.options";
include "/etc/bind/named.conf.local";
include "/etc/bind/named.conf.default-zones";
controls {
inet 127.0.0.1 allow { localhost; };
};
statistics-channels {
inet 127.0.0.1 port 80 allow { 127.0.0.1; };
};
zone "test" {
type master;
allow-transfer { any; };
zone-statistics full;
file "/etc/bind/db.test";
};
```
`db.test`` content:
```
test. 604800 IN SOA test. root.test. 1 604800 86400 2419200 604800
test. 604800 IN NS test.
test. 604800 IN A 127.0.0.1
test. 604800 IN AAAA ::1
```
### Relevant logs and/or screenshots
The output of the command described in the "Steps to reproduce" section:
```
# curl -v -d '{}' -o/dev/null http://127.0.0.1:80/json/v1 -o/dev/null http://127.0.0.1:80/json/v1
* Trying 127.0.0.1:80...
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Connected to 127.0.0.1 (127.0.0.1) port 80 (#0)
> POST /json/v1 HTTP/1.1
> Host: 127.0.0.1
> User-Agent: curl/7.81.0
> Accept: */*
> Content-Length: 2
> Content-Type: application/x-www-form-urlencoded
>
} [2 bytes data]
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Content-Type: application/json
< Date: Mon, 04 Jul 2022 07:09:27 GMT
< Expires: Mon, 04 Jul 2022 07:09:27 GMT
< Last-Modified: Mon, 04 Jul 2022 07:09:27 GMT
< Pragma: no-cache
< Cache-Control: no-cache
< Server: libisc
< Content-Length: 58431
<
{ [11824 bytes data]
100 58433 100 58431 100 2 21.7M 782 --:--:-- --:--:-- --:--:-- 27.8M
* Connection #0 to host 127.0.0.1 left intact
* Found bundle for host 127.0.0.1: 0x5568a154fec0 [serially]
* Can not multiplex, even if we wanted to!
* Re-using existing connection! (#0) with host 127.0.0.1
* Connected to 127.0.0.1 (127.0.0.1) port 80 (#0)
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0> POST /json/v1 HTTP/1.1
> Host: 127.0.0.1
> User-Agent: curl/7.81.0
> Accept: */*
> Content-Length: 2
> Content-Type: application/x-www-form-urlencoded
>
} [2 bytes data]
* Connection died, retrying a fresh connect (retry count: 1)
^^^^^^^^^^^^^^^^^^^^^ SECOND REQUEST DIES ^^^^^^^^^^^^^^^^^^^^^
100 2 0 0 100 2 0 1282 --:--:-- --:--:-- --:--:-- 2000
* Closing connection 0
* Issue another request to this URL: 'http://127.0.0.1:80/json/v1'
* Hostname 127.0.0.1 was found in DNS cache
* Trying 127.0.0.1:80...
* Connected to 127.0.0.1 (127.0.0.1) port 80 (#1)
> POST /json/v1 HTTP/1.1
> Host: 127.0.0.1
> User-Agent: curl/7.81.0
> Accept: */*
> Content-Length: 2
> Content-Type: application/x-www-form-urlencoded
>
} [2 bytes data]
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Content-Type: application/json
< Date: Mon, 04 Jul 2022 07:09:27 GMT
< Expires: Mon, 04 Jul 2022 07:09:27 GMT
< Last-Modified: Mon, 04 Jul 2022 07:09:27 GMT
< Pragma: no-cache
< Cache-Control: no-cache
< Server: libisc
< Content-Length: 58431
<
{ [35984 bytes data]
100 58433 100 58431 100 2 11.4M 409 --:--:-- --:--:-- --:--:-- 11.4M
* Connection #1 to host 127.0.0.1 left intact
```
### Possible fixes
The requests with the empty bodies are accepted correctly with both POST and GET methods.September 2022 (9.16.33, 9.16.33-S1, 9.18.7, 9.19.5)Arаm SаrgsyаnArаm Sаrgsyаnhttps://gitlab.isc.org/isc-projects/stork/-/issues/814Invalid host updating2022-08-17T15:06:56ZSlawek FigielInvalid host updating@kpfleming wrote in Stork mailing list:
> I've had a pair of Kea DHCP servers (for both IPv4 and IPv6) running
for a few months now, with Stork setup to monitor them. The Kea
servers are in HA mode, so they have nearly identical configu...@kpfleming wrote in Stork mailing list:
> I've had a pair of Kea DHCP servers (for both IPv4 and IPv6) running
for a few months now, with Stork setup to monitor them. The Kea
servers are in HA mode, so they have nearly identical configurations.
>
> Those configurations include 20+ host reservations, and those
reservations have always shown up in the Stork 'Host Reservations'
display as they should. However the 'Hostname' column was always
empty, because I didn't have hostnames specified in the Kea
configuration files.
>
> Today I changed that, and applied hostnames to all of the
reservations, then did a 'reload' of the Kea DHCP servers. The Stork
dashboard noted that the configuration had been changed, but still
does not show the hostnames. I've waited a few hours to see if it was
just going to update later, but it has not updated.
>
> Is there something I need to do to trigger Stork to re-read this data
from the configuration files? I've included an excerpt of the config
file below just in case I've done something incorrectly there.
I confirm the bug. The host reservation data doesn't update if the host identifier or reserved IP doesn't change.1.6Slawek FigielSlawek Figielhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3459RRL wildcard special-case strips only a single label2022-09-21T11:34:33ZPeter DaviesRRL wildcard special-case strips only a single labelThe following received by Security Officer:
I think I've found a bug in the request-rate limiting logic. The issue
is that the RRL logic for wildcard domains strips exactly 1 label from
the domain.
The idea is that a million u...The following received by Security Officer:
I think I've found a bug in the request-rate limiting logic. The issue
is that the RRL logic for wildcard domains strips exactly 1 label from
the domain.
The idea is that a million unique queries with one src addr for
*.example.com should be treated as a million identical queries for
example.com (triggering the RRL).
However, *.example.com will match any.number.of.labels.example.com, so
stripping a single label is insufficient. An attacker who can spoof
their source IP is able to send a million queries of
x.$UNIQUE.example.com, the RRL strips the x, and sees a million unique
queries still.
Is there a flag somewhere that limits wildcards to matching a single
label? If not, this seems like a security issue because it opens any
authoritative name server with a wildcard record to be hijacked for
reflection attacks.
I've verified the bug exists with the latest development version of bind
available on isc.org (9.19.2).
For reproducing, I've included a query.c file that will run 100 queries
against a nameserver. Read the source code or compile it and run it
without arguments for details on using it.
But if you have a local bind server serving a *.example.com record, you
can reproduce the behavior by running:
```
# the $ means "make this label always unique"
./query $.example.com
```
which will hang after hitting the RRL limit, and then running
```
./query x.$.example.com
```
which will finish all 100 queries without issue.[query.c](/uploads/ba6f80b4e92ab4dec500d1f40cc886b6/query.c)September 2022 (9.16.33, 9.16.33-S1, 9.18.7, 9.19.5)Arаm SаrgsyаnArаm Sаrgsyаnhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3458Reintroduce testing with --without-cmocka and --without-gssapi2022-09-06T08:38:33ZMichal NowakReintroduce testing with --without-cmocka and --without-gssapiWith Debian 9 removal (aa86a8bcf0aaa25f678cf0fcd22050e8ce084227) we lost building with `--without-cmocka` and `--without-gssapi` `./configure` options. It hasn't been explicitly discussed in isc-projects/bind9#3408 or isc-projects/bind9!...With Debian 9 removal (aa86a8bcf0aaa25f678cf0fcd22050e8ce084227) we lost building with `--without-cmocka` and `--without-gssapi` `./configure` options. It hasn't been explicitly discussed in isc-projects/bind9#3408 or isc-projects/bind9!6486.
An inadvertent change, @pspacek?September 2022 (9.16.33, 9.16.33-S1, 9.18.7, 9.19.5)Michal NowakMichal Nowakhttps://gitlab.isc.org/isc-projects/stork/-/issues/812Manually provided DHCP option in host reservation form produces backend error2022-08-30T12:02:17ZSlawek FigielManually provided DHCP option in host reservation form produces backend errorThe issue found during the 1.5 sanity checks [Source](https://gitlab.isc.org/isc-projects/stork/-/issues/808#note_300620)
Providing option code by hand in the host reservation form causes GO unmarshal error. Selecting the option code fr...The issue found during the 1.5 sanity checks [Source](https://gitlab.isc.org/isc-projects/stork/-/issues/808#note_300620)
Providing option code by hand in the host reservation form causes GO unmarshal error. Selecting the option code from the dropdown works well, the option is forwarded to the Kea.
Error:
```
Cannot commit new host
The transaction adding new host failed: parsing host body from "" failed, because json: cannot unmarshal string into Go struct field DHCPOption.localHosts.options.code of type int64
```
Parameters to reproduce:
* Global reservation: true
* DHCP Servers: kea@agent-kea-premium/dhcp6
* DHCP Identifier: flex-id / text / xa<zsc
* IP Reservations: IPv6 address / 2001:db8:1::2
* DHCP options:
* Option code: 92 (manually provided)
* Payload: hex-bytes 1234451.6Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/stork/-/issues/810Deploy demo doesn't work2022-08-17T15:06:56ZSlawek FigielDeploy demo doesn't workWe changed the name of the running demo script in #761, but we forgot to update the Gitlab CI YAML. The deploy demo CI tasks fail now due to a missing file.We changed the name of the running demo script in #761, but we forgot to update the Gitlab CI YAML. The deploy demo CI tasks fail now due to a missing file.1.6Slawek FigielSlawek Figielhttps://gitlab.isc.org/isc-projects/stork/-/issues/802System tests fail on none config reports2022-08-23T10:34:07ZSlawek FigielSystem tests fail on none config reportsRefers to: `test_get_dhcp4_config_review_reports` test case.
The Stork Server returns HTTP 204 No Content status if the config review is not performed yet for a given daemon. It is correctly described in the Swagger YAML file. The serve...Refers to: `test_get_dhcp4_config_review_reports` test case.
The Stork Server returns HTTP 204 No Content status if the config review is not performed yet for a given daemon. It is correctly described in the Swagger YAML file. The server sends only HTTP status and no data in response.
Unfortunately, it seems that the Python OpenAPI client doesn't support No Content status and always expects that the config reviews will be included in the server response.
It causes the system tests may sporadically fail on listing the reviews. Additionally, we need a function to wait for complete review for a given daemon.1.6