BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2022-03-20T16:27:14Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3166uvreq freed too early from isc_nm_connecttimeout_cb()2022-03-20T16:27:14ZOndřej Surýuvreq freed too early from isc_nm_connecttimeout_cb()The `isc__nm_uvreq_t` is marked as unused too early in the `isc__nm_connecttimeout_cb()`, the `isc__nm_uvreq_put()` needs to be called from the original connection callback.
Under normal circumstances, this is not a problem because the ...The `isc__nm_uvreq_t` is marked as unused too early in the `isc__nm_connecttimeout_cb()`, the `isc__nm_uvreq_put()` needs to be called from the original connection callback.
Under normal circumstances, this is not a problem because the `isc__nm_uvreq_t` is put onto `sock->inactivereqs` and freed when the `isc__nmsocket_t` is destroyed.March 2022 (9.11.37, 9.11.37-S1, 9.16.27, 9.16.27-S1, 9.18.1)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3164missing semicolon in the parental-agents-documentation2022-02-22T13:20:50ZThomas Amgartenmissing semicolon in the parental-agents-documentationIn the BIND9 documentation [https://bind9.readthedocs.io/en/latest/dnssec-guide.html?highlight=parental-agents#working-with-the-parent-zone-2](https://bind9.readthedocs.io/en/latest/dnssec-guide.html?highlight=parental-agents#working-wit...In the BIND9 documentation [https://bind9.readthedocs.io/en/latest/dnssec-guide.html?highlight=parental-agents#working-with-the-parent-zone-2](https://bind9.readthedocs.io/en/latest/dnssec-guide.html?highlight=parental-agents#working-with-the-parent-zone-2) the mentioned code-snipped will not load:
```
...
parental-agents "net" {
10.53.0.11, 10.53.0.12;
};
...
```
The parental IPs needs to be delimited with a semicolon, otherwise BIND will not start/load:
```
22-Feb-2022 11:05:08.964 config: error: /etc/named/named.conf:23: missing ';' before '10.53.0.12'
```
The correct documentation - which starts BIND successfully - should be:
```
parental-agents "net" {
10.53.0.11; 10.53.0.12;
};
```March 2022 (9.11.37, 9.11.37-S1, 9.16.27, 9.16.27-S1, 9.18.1)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/3158[CVE-2022-0635] DNAME lookups can trigger INSIST when synth-from-dnssec is en...2022-04-21T08:07:18ZMichal Nowak[CVE-2022-0635] DNAME lookups can trigger INSIST when synth-from-dnssec is enabledLookups involving a `DNAME` could trigger an `INSIST` when `synth-from-dnssec` is enabled.
https://wiki.isc.org/bin/view/Main/SecurityIncident202202DNAMELookupsINSISTWhenSynthFromDnssecEnabled
### CVE-specific actions
- [x] Assign a...Lookups involving a `DNAME` could trigger an `INSIST` when `synth-from-dnssec` is enabled.
https://wiki.isc.org/bin/view/Main/SecurityIncident202202DNAMELookupsINSISTWhenSynthFromDnssecEnabled
### CVE-specific actions
- [x] Assign a CVE identifier
- [x] Determine CVSS score
- [x] Determine the range of BIND versions affected (including the Subscription Edition)
- 9.18.0
- [x] Determine whether workarounds for the problem exists
- Issue can be mitigated by setting `synth-from-dnssec no;`.
- [x] Create a draft of the security advisory and put the information above in there
- https://mattermost.isc.org/isc/channels/cve-2022-0635-dname-insist-with-synth-from-dnssec-enabled/1ksboiszftncxkpfjpeiafm19o
- [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)
- `synthfromdnssec` system test in isc-private/bind9!370
- explanation of code flow which triggers the problem (a system test is *not* good enough)
- https://gitlab.isc.org/isc-projects/bind9/-/issues/3158#note_267910
- [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)
- isc-private/bind9!370
- a fix for the issue
- isc-private/bind9!390
- documentation updates (`CHANGES`, release notes, anything else applicable)
- isc-private/bind9!390
- [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
- https://gitlab.isc.org/isc-private/bind9/-/merge_requests/368#note_268053
- [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)
- ~"v9.18" isc-private/bind9!391 & isc-private/bind9!372
- [x] Prepare a standalone patch for the last stable release of each affected (and still maintained) BIND branch
- patch for BIND 9.18.0 release derived from [isc-private/bind9!391 diff](https://gitlab.isc.org/isc-private/bind9/-/merge_requests/391.diff) and stripped of documentation changes: [391.diff](/uploads/21fd3bf8fb9bbf7a0e01ca5c8b7a310a708a99cb/391.diff)
### Release-specific actions
- [x] [Create/update the private issue containing links to fixes & reproducers for all CVEs fixed in a given release cycle](isc-private/bind9#49)
- [x] [Reserve a block of `CHANGES` placeholders once the complete set of vulnerabilities fixed in a given release cycle is determined](!5925)
- [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 branchesMarch 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/3157Blackhole option anomaly2022-11-25T17:07:53ZthibmacBlackhole option anomaly### Summary
Using the following option seems to block AXFR queries and rndc commands
`blackhole { none; };`
I also reported this behaviour here : https://lists.isc.org/pipermail/bind-users/2022-February/105709.html
### BIND version u...### Summary
Using the following option seems to block AXFR queries and rndc commands
`blackhole { none; };`
I also reported this behaviour here : https://lists.isc.org/pipermail/bind-users/2022-February/105709.html
### BIND version used
Most likely started in 9.17.19
Not present in 9.17.15 -> 9.17.19
Present in 9.17.19 -> 9.18.0
### Steps to reproduce
Setup two authoritative servers (1 primary and 1 master)
Allow AXFR transfer from one to another
Try using and commenting the following option
`blackhole { none; };`
I have tested in different configuration setups (in case of a conflict with an other option), and I'm seeing the same behaviour.
### What is the current *bug* behavior?
Zones update on the primary servers are not applied to the secondary servers
The primary stops sending notify queries and the secondary is unable to transfer the zone
However, AXFR queries with dig keep answering as expected.
These rndc commands are ignored (checked with tcpdump packet capture)
- retransfer
- refresh
Nothing is logged
Zone also doesn't refresh when the Refresh timer described in SOA expires.
### What is the expected *correct* behavior?
I'm expecting zone transfers to keep functioning whenever the zone is update on the primary server.
Notify queries sent and logged (and visible in logfiles and packet capture)
### Relevant configuration files
```
options {
blackhole {
"none";
};
directory "/named/database";
dump-file "/named/database/dump_named.txt";
};
listen-on port 53 {
192.168.10.1/32;
};
pid-file "/named/etc/named.pid";
server-id "1";
recursion no;
also-notify {
192.168.10.2/32;
};
allow-transfer {
192.168.10.2/32;
};
zone-statistics no;
};
```
### Relevant logs and/or screenshots
None
### Possible fixes
Commenting `blackhole { none; };` restores the expected behaviour`
Also, blackholing a random IP also restores the expected behaviour.
Not really sure how that parameter exactly works, but it would seem like `blackhole { none; };` is interpreted as a `blackhole { all; };` here.March 2022 (9.11.37, 9.11.37-S1, 9.16.27, 9.16.27-S1, 9.18.1)Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/3151v9_18_0 compiled failed2022-02-14T10:45:05Zshipei.xuv9_18_0 compiled failed![image](/uploads/ff55b5d2d10e01c15987eaf8f33e8d06/image.png)![image](/uploads/ff55b5d2d10e01c15987eaf8f33e8d06/image.png)March 2022 (9.11.37, 9.11.37-S1, 9.16.27, 9.16.27-S1, 9.18.1)https://gitlab.isc.org/isc-projects/bind9/-/issues/3150INSIST failure processing DNAME in query_dname2022-04-21T08:08:01ZMark AndrewsINSIST failure processing DNAME in query_dnameSupport has reports of assertion failures on lookups involving DNAME. https://support.isc.org/Ticket/Display.html?id=20155
Queries for www.voyage-ile-de-france.fr can cause a RUNTIME_CHECK failure in query.c:query_dname.
```
; <<>> Di...Support has reports of assertion failures on lookups involving DNAME. https://support.isc.org/Ticket/Display.html?id=20155
Queries for www.voyage-ile-de-france.fr can cause a RUNTIME_CHECK failure in query.c:query_dname.
```
; <<>> DiG 9.16.22 <<>> @nscache02.mrs.prive.nic.fr www.voyage-ile-de-france.fr
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47904
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: e4810fabca4bf153010000006207e34d4f199e76a4d6fca8 (good)
;; QUESTION SECTION:
;www.voyage-ile-de-france.fr. IN A
;; ANSWER SECTION:
voyage-ile-de-france.fr. 3595 IN DNAME pagesjaunes.fr.
www.voyage-ile-de-france.fr. 3595 IN CNAME www.pagesjaunes.fr.
www.pagesjaunes.fr. 295 IN CNAME www.pagesjaunes.fr.cdn.cloudflare.net.
www.pagesjaunes.fr.cdn.cloudflare.net. 295 IN A 104.19.237.56
www.pagesjaunes.fr.cdn.cloudflare.net. 295 IN A 104.19.236.56
;; Query time: 24 msec
;; SERVER: 2001:67c:2219:15::163#53(2001:67c:2219:15::163)
;; WHEN: Sat Feb 12 16:41:49 UTC 2022
;; MSG SIZE rcvd: 213
```
One example stack trace (late 9.17) below.
```
Thread 1 Crashed:
0 libsystem_kernel.dylib 0x0000000192a80e68 __pthread_kill + 8
1 libsystem_pthread.dylib 0x0000000192ab343c pthread_kill + 292
2 libsystem_c.dylib 0x00000001929fb454 abort + 124
3 named 0x0000000102e6a9d0 assertion_failed + 552 (main.c:238)
4 libisc-9.17.22.dylib 0x0000000103282258 isc_assertion_failed + 56 (assertions.c:49)
5 libns-9.17.22.dylib 0x0000000102f29a6c query_dname + 380 (query.c:10520)
6 libns-9.17.22.dylib 0x0000000102f25d28 query_gotanswer + 1076 (query.c:7648)
7 libns-9.17.22.dylib 0x0000000102f210c0 query_lookup + 1996 (query.c:6003)
8 libns-9.17.22.dylib 0x0000000102f35e00 query_zone_delegation + 1280 (query.c:8808)
9 libns-9.17.22.dylib 0x0000000102f279cc query_delegation + 280 (query.c:8836)
10 libns-9.17.22.dylib 0x0000000102f25c7c query_gotanswer + 904 (query.c:7621)
11 libns-9.17.22.dylib 0x0000000102f210c0 query_lookup + 1996 (query.c:6003)
12 libns-9.17.22.dylib 0x0000000102f1fb6c ns__query_start + 2012 (query.c:5643)
13 libns-9.17.22.dylib 0x0000000102f24a04 query_setup + 368 (query.c:5357)
14 libns-9.17.22.dylib 0x0000000102f241c4 ns_query_start + 1684 (query.c:12222)
15 libns-9.17.22.dylib 0x0000000102f15c44 ns__client_request + 5152 (client.c:2225)
16 libisc-9.17.22.dylib 0x000000010326b31c isc__nm_async_readcb + 408 (netmgr.c:2798)
17 libisc-9.17.22.dylib 0x000000010326b130 isc__nm_readcb + 304 (netmgr.c:2771)
18 libisc-9.17.22.dylib 0x000000010327d880 udp_recv_cb + 676 (udp.c:642)
19 libuv.1.dylib 0x0000000103eee99c uv__udp_io + 288
20 libuv.1.dylib 0x0000000103ef1aac uv__io_poll + 1592
21 libuv.1.dylib 0x0000000103ee25f0 uv_run + 320
22 libisc-9.17.22.dylib 0x00000001032616b0 nm_thread + 84 (netmgr.c:691)
23 libisc-9.17.22.dylib 0x00000001032bae28 isc__trampoline_run + 52 (trampoline.c:187)
24 libsystem_pthread.dylib 0x0000000192ab3878 _pthread_start + 320
25 libsystem_pthread.dylib 0x0000000192aae5e0 thread_start + 8
```
The INSIST in question:
```
/*
* Compare the current qname to the found name. We need
* to know how many labels and bits are in common because
* we're going to have to split qname later on.
*/
namereln = dns_name_fullcompare(qctx->client->query.qname, qctx->fname,
&order, &nlabels);
INSIST(namereln == dns_namereln_subdomain);
```
when I added code to log the two names when `namereln != dns_namereln_subdomain` I got:
```
15-Feb-2022 21:03:19.019 client @0x130081368 ::1#49227 (www.voyage-ile-de-france.fr): view secure: namereln=dns_namereln_commonancestor, qctx->client->query.qname=www.voyage-ile-de-france.fr, qctx->fname=proxy.mythic-beasts.com
15-Feb-2022 21:03:19.021 query.c:10539: INSIST(namereln == dns_namereln_subdomain) failed, back trace
```March 2022 (9.11.37, 9.11.37-S1, 9.16.27, 9.16.27-S1, 9.18.1)https://gitlab.isc.org/isc-projects/bind9/-/issues/3149Drop the TCP connection when garbage is received2022-02-25T14:20:12ZOndřej SurýDrop the TCP connection when garbage is receivedWhen garbage (something that isn’t even DNS message) is received over TCP, we should drop (reset) the whole connection instead of trying to salvage it. There’s already call for that, but it applies only to DoH.When garbage (something that isn’t even DNS message) is received over TCP, we should drop (reset) the whole connection instead of trying to salvage it. There’s already call for that, but it applies only to DoH.March 2022 (9.11.37, 9.11.37-S1, 9.16.27, 9.16.27-S1, 9.18.1)https://gitlab.isc.org/isc-projects/bind9/-/issues/3147Underflow of the RecursClients counter crashes named during respdiff tests2022-02-25T14:36:37ZMichał KępieńUnderflow of the RecursClients counter crashes named during respdiff testsOn the first run after !2453 got merged, the respdiff tests crashed due
to a statistics counter underflow:
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/2286800
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/2286801
<detai...On the first run after !2453 got merged, the respdiff tests crashed due
to a statistics counter underflow:
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/2286800
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/2286801
<details>
<summary>Click to expand/collapse log excerpt</summary>
```
11-Feb-2022 00:28:28.644 SERVFAIL unexpected RCODE resolving '_.233.124.88.in-addr.arpa/A/IN': 193.0.9.6#53
11-Feb-2022 00:28:29.772 timed out resolving 'ars-tv.ru/MX/IN': 83.242.151.118#53
11-Feb-2022 00:28:29.904 REFUSED unexpected RCODE resolving 'ars-tv.ru/MX/IN': 176.192.105.132#53
11-Feb-2022 00:28:29.904 query client=0x7f13d4405170 thread=0x7f13d8bf4700(ars-tv.ru/MX): query_gotanswer: unexpected error: failure
11-Feb-2022 00:28:30.084 stats.c:118: REQUIRE(__atomic_fetch_sub (((&stats->counters[counter])), ((1)), (memory_order_release)) > 0) failed, back trace
11-Feb-2022 00:28:30.084 /builds/isc-projects/bind9/bin/named/.libs/named(+0x1fc3f) [0x556bfdedbc3f]
11-Feb-2022 00:28:30.084 /builds/isc-projects/bind9/lib/isc/.libs/libisc-9.17.22.so(isc_assertion_failed+0xa) [0x7f13e2ea5362]
11-Feb-2022 00:28:30.084 /builds/isc-projects/bind9/lib/isc/.libs/libisc-9.17.22.so(isc_stats_dump+0) [0x7f13e2ec2f0c]
11-Feb-2022 00:28:30.084 /builds/isc-projects/bind9/lib/ns/.libs/libns-9.17.22.so(ns_stats_decrement+0x1a) [0x7f13e2c2fcb0]
11-Feb-2022 00:28:30.084 /builds/isc-projects/bind9/lib/ns/.libs/libns-9.17.22.so(+0x34ace) [0x7f13e2c2dace]
11-Feb-2022 00:28:30.084 /builds/isc-projects/bind9/lib/isc/.libs/libisc-9.17.22.so(+0x557f3) [0x7f13e2ec67f3]
11-Feb-2022 00:28:30.084 /builds/isc-projects/bind9/lib/isc/.libs/libisc-9.17.22.so(isc_task_run+0x9) [0x7f13e2ec690e]
11-Feb-2022 00:28:30.084 /builds/isc-projects/bind9/lib/isc/.libs/libisc-9.17.22.so(+0x1d88c) [0x7f13e2e8e88c]
11-Feb-2022 00:28:30.084 /builds/isc-projects/bind9/lib/isc/.libs/libisc-9.17.22.so(+0x23b5c) [0x7f13e2e94b5c]
11-Feb-2022 00:28:30.084 /builds/isc-projects/bind9/lib/isc/.libs/libisc-9.17.22.so(+0x24340) [0x7f13e2e95340]
11-Feb-2022 00:28:30.084 /builds/isc-projects/bind9/lib/isc/.libs/libisc-9.17.22.so(+0x248ff) [0x7f13e2e958ff]
11-Feb-2022 00:28:30.084 /builds/isc-projects/bind9/lib/isc/.libs/libisc-9.17.22.so(+0x24956) [0x7f13e2e95956]
11-Feb-2022 00:28:30.084 /usr/lib/x86_64-linux-gnu/libuv.so.1(+0x10e83) [0x7f13e282fe83]
11-Feb-2022 00:28:30.084 /usr/lib/x86_64-linux-gnu/libuv.so.1(+0x2cb87) [0x7f13e284bb87]
11-Feb-2022 00:28:30.084 /usr/lib/x86_64-linux-gnu/libuv.so.1(uv_run+0xb1) [0x7f13e283086c]
11-Feb-2022 00:28:30.084 /builds/isc-projects/bind9/lib/isc/.libs/libisc-9.17.22.so(+0x24412) [0x7f13e2e95412]
11-Feb-2022 00:28:30.084 /builds/isc-projects/bind9/lib/isc/.libs/libisc-9.17.22.so(isc__trampoline_run+0x16) [0x7f13e2ecd5ba]
11-Feb-2022 00:28:30.084 /lib/x86_64-linux-gnu/libpthread.so.0(+0x8ea7) [0x7f13e25f8ea7]
11-Feb-2022 00:28:30.084 /lib/x86_64-linux-gnu/libc.so.6(clone+0x3f) [0x7f13e2528def]
11-Feb-2022 00:28:30.084 exiting (due to assertion failure)
```
</details>
<details>
<summary>Click to expand/collapse GDB backtrace</summary>
```
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1 0x00007f13e2450537 in __GI_abort () at abort.c:79
#2 0x0000556bfdedbd96 in assertion_failed (file=<optimized out>, line=<optimized out>, type=isc_assertiontype_require,
cond=0x7f13e2ee7110 "__atomic_fetch_sub (((&stats->counters[counter])), ((1)), (memory_order_release)) > 0") at main.c:238
#3 0x00007f13e2ea5362 in isc_assertion_failed (file=file@entry=0x7f13e2ee7215 "stats.c", line=line@entry=118, type=type@entry=isc_assertiontype_require,
cond=cond@entry=0x7f13e2ee7110 "__atomic_fetch_sub (((&stats->counters[counter])), ((1)), (memory_order_release)) > 0") at assertions.c:49
#4 0x00007f13e2ec2f0c in isc_stats_decrement (stats=<optimized out>, counter=counter@entry=36) at stats.c:118
#5 0x00007f13e2c2fcb0 in ns_stats_decrement (stats=<optimized out>, counter=counter@entry=36) at stats.c:105
#6 0x00007f13e2c2dace in fetch_callback (task=<optimized out>, event=<optimized out>) at query.c:6186
#7 0x00007f13e2ec67f3 in task_run (task=0x7f13d76c56c0) at task.c:821
#8 0x00007f13e2ec690e in isc_task_run (task=<optimized out>) at task.c:901
#9 0x00007f13e2e8e88c in isc__nm_async_task (worker=worker@entry=0x7f13dfa36240, ev0=ev0@entry=0x7f1395dc6200) at netmgr/netmgr.c:837
#10 0x00007f13e2e94b5c in process_netievent (worker=worker@entry=0x7f13dfa36240, ievent=0x7f1395dc6200) at netmgr/netmgr.c:916
#11 0x00007f13e2e95340 in process_queue (worker=worker@entry=0x7f13dfa36240, type=type@entry=NETIEVENT_TASK) at netmgr/netmgr.c:1010
#12 0x00007f13e2e958ff in process_all_queues (worker=0x7f13dfa36240) at netmgr/netmgr.c:756
#13 0x00007f13e2e95956 in async_cb (handle=0x7f13dfa365a0) at netmgr/netmgr.c:785
#14 0x00007f13e282fe83 in uv__async_io (loop=0x7f13dfa36250, w=0x7f13dfa36418, events=1) at /usr/src/libuv-v1.43.0/src/unix/async.c:163
#15 0x00007f13e284bb87 in uv__io_poll (loop=0x7f13dfa36250, timeout=-1) at /usr/src/libuv-v1.43.0/src/unix/epoll.c:374
#16 0x00007f13e283086c in uv_run (loop=0x7f13dfa36250, mode=UV_RUN_DEFAULT) at /usr/src/libuv-v1.43.0/src/unix/core.c:389
#17 0x00007f13e2e95412 in nm_thread (worker0=0x7f13dfa36240) at netmgr/netmgr.c:691
#18 0x00007f13e2ecd5ba in isc__trampoline_run (arg=0x556bfe629b70) at trampoline.c:187
#19 0x00007f13e25f8ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
#20 0x00007f13e2528def in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
```
</details>
The backtrace shows that the crashing call is in `fetch_callback()`:
```c
6180 /*
6181 * We're done recursing, detach from quota and unlink from
6182 * the manager's recursing-clients list.
6183 */
6184
6185 if (client->recursionquota != NULL) {
6186 isc_quota_detach(&client->recursionquota);
6187 >>> ns_stats_decrement(client->sctx->nsstats,
6188 >>> ns_statscounter_recursclients);
```
(The backtrace is identical for both jobs linked to above.)March 2022 (9.11.37, 9.11.37-S1, 9.16.27, 9.16.27-S1, 9.18.1)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3141Remove artificial limit on number of pipelined TCP queries2024-01-25T10:59:49ZOndřej SurýRemove artificial limit on number of pipelined TCP queriesThere's a artificial limit (`23`) on the number of pipelined TCP queries processed at the same time. We need to remove the limit and test the impact.There's a artificial limit (`23`) on the number of pipelined TCP queries processed at the same time. We need to remove the limit and test the impact.March 2022 (9.11.37, 9.11.37-S1, 9.16.27, 9.16.27-S1, 9.18.1)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3137BIND task-exclusive mode - create new log messages when entering and exiting ...2022-02-25T14:00:10ZGreg ChoulesBIND task-exclusive mode - create new log messages when entering and exiting this mode."task-exclusive" mode is entered when some kinds of processing need to be performed. For visibility, it would be useful if BIND logged when this mode was being entered and exited."task-exclusive" mode is entered when some kinds of processing need to be performed. For visibility, it would be useful if BIND logged when this mode was being entered and exited.March 2022 (9.11.37, 9.11.37-S1, 9.16.27, 9.16.27-S1, 9.18.1)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3133Some TCP error conditions are handled incorrectly2022-02-25T14:29:32ZMichał KępieńSome TCP error conditions are handled incorrectlyIn `lib/dns/dispatch.c:tcp_recv()`, the `default` case in the second
`switch` statement is overly broad and causes some result codes provided
by netmgr to be incorrectly overridden with `ISC_R_SHUTTINGDOWN`. This
enables e.g. `shutting ...In `lib/dns/dispatch.c:tcp_recv()`, the `default` case in the second
`switch` statement is overly broad and causes some result codes provided
by netmgr to be incorrectly overridden with `ISC_R_SHUTTINGDOWN`. This
enables e.g. `shutting down resolving ...` messages to be logged in the
middle of normal resolver operation (which is confusing as such messages
are only supposed to be logged when the netmgr is being shut down
entirely) and causes some error conditions to be mishandled by resolver
code (`resquery_response()`).
As an example, consider what happens if `tcp_recv()` gets invoked with
the `ISC_R_EOF` result code:
1. The first `switch` statement calls `tcp_recv_shutdown()` to prepare
the dispatch for cleanup.
2. The `result` variable remains untouched.
3. The second `switch` statement matches `ISC_R_EOF` to the `default`
case.
4. `tcp_recv_cancelall()` gets called, which causes the higher-level
dispatch callback (`resquery_response()`) to be invoked with the
`ISC_R_SHUTTINGDOWN` result code.
5. Instead of returning early (which should happen for `ISC_R_EOF`),
`resquery_response()` continues to process the `ISC_R_SHUTTINGDOWN`
result code, eventually reaching `rctx_dispfail()` and marking the
server as bad.
At least two other error conditions (`ISC_R_CANCELED` and
`ISC_R_CONNECTIONRESET`) can be similarly overridden with
`ISC_R_SHUTTINGDOWN`.
AIUI, the original netmgr error code should be propagated to the
resolver code so that it can be handled accordingly. Perhaps something
like this could work?
```diff
diff --git a/lib/dns/dispatch.c b/lib/dns/dispatch.c
index c13d91d0642..81e2f0658d7 100644
--- a/lib/dns/dispatch.c
+++ b/lib/dns/dispatch.c
@@ -713,13 +713,14 @@ tcp_recv_done(dns_dispentry_t *resp, isc_result_t eresult,
}
static void
-tcp_recv_cancelall(dns_displist_t *resps, isc_region_t *region) {
+tcp_recv_cancelall(dns_displist_t *resps, isc_region_t *region,
+ isc_result_t result) {
dns_dispentry_t *resp = NULL, *next = NULL;
for (resp = ISC_LIST_HEAD(*resps); resp != NULL; resp = next) {
next = ISC_LIST_NEXT(resp, rlink);
ISC_LIST_UNLINK(*resps, resp, rlink);
- resp->response(ISC_R_SHUTTINGDOWN, region, resp->arg);
+ resp->response(result, region, resp->arg);
dispentry_detach(&resp);
}
}
@@ -831,7 +832,7 @@ tcp_recv(isc_nmhandle_t *handle, isc_result_t result, isc_region_t *region,
break;
default:
/* We're being shut down; cancel all outstanding resps. */
- tcp_recv_cancelall(&resps, region);
+ tcp_recv_cancelall(&resps, region, result);
}
dns_dispatch_detach(&disp);
```March 2022 (9.11.37, 9.11.37-S1, 9.16.27, 9.16.27-S1, 9.18.1)Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/3132netmgr is missing TCP send timeout2022-02-25T14:17:13ZOndřej Surýnetmgr is missing TCP send timeoutWhen the `uv_write()` fills up the TCP send buffers (around 208k) on Linux because the other side is not reading, the TCP connection will be kept open indefinitely.
We need to add a "idle" timer around the `uv_write()`, so we can bail o...When the `uv_write()` fills up the TCP send buffers (around 208k) on Linux because the other side is not reading, the TCP connection will be kept open indefinitely.
We need to add a "idle" timer around the `uv_write()`, so we can bail out early.
This also affects #1897 - the XFR timeout works fine, but the connection gets stuck as we have no way of terminating the pending `uv_write()`s on the stuck transfer.
FTR This is not CVE/ASN worthy because there's even a simpler way to keep the TCP connection open indefinitely - just keep sending and reading the DNS queries/responses, but keeping this confidential for the time being.March 2022 (9.11.37, 9.11.37-S1, 9.16.27, 9.16.27-S1, 9.18.1)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3130build for Android failed2022-02-25T13:53:20Zfpliubuild for Android failed![30](/uploads/f938bff0f327cf2f669a192af25fb740/30.PNG)
https://downloads.isc.org/isc/bind9/9.18.0/bind-9.18.0.tar.xz
relevant code at [lib/isc/thread.c#L100-102](https://gitlab.isc.org/isc-projects/bind9/-/blob/main/lib/isc/thread.c#L...![30](/uploads/f938bff0f327cf2f669a192af25fb740/30.PNG)
https://downloads.isc.org/isc/bind9/9.18.0/bind-9.18.0.tar.xz
relevant code at [lib/isc/thread.c#L100-102](https://gitlab.isc.org/isc-projects/bind9/-/blob/main/lib/isc/thread.c#L100-102) should look like:
```c
#if (defined(__NetBSD__) || defined(__ANDROID__))
```March 2022 (9.11.37, 9.11.37-S1, 9.16.27, 9.16.27-S1, 9.18.1)https://gitlab.isc.org/isc-projects/bind9/-/issues/3129[CVE-2022-0667] assertion failure on delayed DS lookup2022-11-10T14:07:26ZPetr Špačekpspacek@isc.org[CVE-2022-0667] assertion failure on delayed DS lookup<!--
THIS ISSUE TEMPLATE IS INTENDED ONLY FOR INTERNAL USE.
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 - the...<!--
THIS ISSUE TEMPLATE IS INTENDED ONLY FOR INTERNAL USE.
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).
-->
### CVE-specific actions
- [x] Assign a CVE identifier
- [x] Determine CVSS score 7.0
- AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H/E:F/RL:O/RC:C
- [x] Determine the range of BIND versions affected (including the Subscription Edition)
- 9.18.0
- [x] Determine whether workarounds for the problem exists
- No workaround exits
- [x] Create a draft of the security advisory and put the information above in there
- https://portal.document360.io/956e37e2-5ec0-4942-8b27-35533899f099/document/v1/view/153f2922-2ac3-47ac-b8f4-a5f44be40e79
- [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)
- explanation of code flow which triggers the problem (a system test is *not* good enough)
- [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 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](isc-private/bind9#49)
- [x] [Reserve a block of `CHANGES` placeholders once the complete set of vulnerabilities fixed in a given release cycle is determined](!5925)
- [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
### Summary
BIND crashes when under heavy cache-miss load, while configured to forward queries to some other recursor.
### BIND version used
~"Affects v9.18" : v9.18.0
Other versions are under investigation.
### Steps to reproduce
Well, that's a problem. It happens only under load, when forwarding, and only when _some_ timeouts happen.
### What is the current *bug* behavior?
Crash on assert:
```
assertion_failed (file=0x7fea3376b05b "resolver.c", line=7117, type=isc_assertiontype_insist, cond=0x7fea3376b3a6 "__v > 0")
```
<details>
GDB
```
(gdb) bt
#0 0x00007fea3288ad22 in raise () from /usr/lib/libc.so.6
#1 0x00007fea32874862 in abort () from /usr/lib/libc.so.6
#2 0x000055fad8cb1821 in assertion_failed (file=0x7fea3376b05b "resolver.c", line=7117, type=isc_assertiontype_insist, cond=0x7fea3376b3a6 "__v > 0") at main.c:238
#3 0x00007fea337f88da in isc_assertion_failed (file=0x7fea3376b05b "resolver.c", line=7117, type=isc_assertiontype_insist, cond=0x7fea3376b3a6 "__v > 0") at assertions.c:49
#4 0x00007fea3368552f in fctx__detach (fctxp=0x7fea2c8f4a38, file=0x7fea3376b05b "resolver.c", line=7275, func=0x7fea3376f3f0 <__func__.5> "resume_dslookup") at resolver.c:7117
#5 0x00007fea33685c78 in resume_dslookup (task=0x7fea285a85c0, event=0x0) at resolver.c:7275
#6 0x00007fea33826e35 in task_run (task=0x7fea285a85c0) at task.c:820
#7 0x00007fea3382705d in isc_task_run (task=0x7fea285a85c0) at task.c:900
#8 0x00007fea337d7b30 in isc__nm_async_task (worker=0x7fea302a9770, ev0=0x7fea28055200) at netmgr/netmgr.c:837
#9 0x00007fea337d7dc4 in process_netievent (worker=0x7fea302a9770, ievent=0x7fea28055200) at netmgr/netmgr.c:916
#10 0x00007fea337d88f9 in process_queue (worker=0x7fea302a9770, type=NETIEVENT_TASK) at netmgr/netmgr.c:1010
#11 0x00007fea337d797c in process_all_queues (worker=0x7fea302a9770) at netmgr/netmgr.c:756
#12 0x00007fea337d7a00 in async_cb (handle=0x7fea302a9ad0) at netmgr/netmgr.c:785
#13 0x00007fea32c2f92d in ?? () from /usr/lib/libuv.so.1
#14 0x00007fea32c4bd0e in ?? () from /usr/lib/libuv.so.1
#15 0x00007fea32c35438 in uv_run () from /usr/lib/libuv.so.1
#16 0x00007fea337d75ab in nm_thread (worker0=0x7fea302a9770) at netmgr/netmgr.c:691
#17 0x00007fea33830a60 in isc__trampoline_run (arg=0x7fea30277ca0) at trampoline.c:187
#18 0x00007fea32a23259 in start_thread () from /usr/lib/libpthread.so.0
#19 0x00007fea3294c5e3 in clone () from /usr/lib/libc.so.6
```
```
(gdb) frame
#4 0x00007fea3368552f in fctx__detach (fctxp=0x7fea2c8f4a38, file=0x7fea3376b05b "resolver.c", line=7275, func=0x7fea3376f3f0 <__func__.5> "resume_dslookup") at resolver.c:7117
(gdb) p /x fctx->references
$2 = 0xffffffffffffffff
```
</details>
### What is the expected *correct* behavior?
Well, no crash :trollface:
### Relevant configuration files
* [named.conf](/uploads/d62d91f99f983549d27a198272642033/named.conf)
* 127.0.0.112 does recursion
I have a suspicion that all tracebacks had function `resume_dslookup` in them. Is this function special in some way?
### Relevant logs and/or screenshots
Original logs were lost, sorry. Generally the log had lots and lots of timeouts and also some "shut down hung fetch" messages.
Here is content of `fctx`:
<details>
```
(gdb) p *fctx
$5 = {magic = 1176576289, res = 0x0, fname = {name = {magic = 1145983854,
ndata = 0x7fea21692120 "\001\061\001\060\001\060\001\060\001\061\001\060\001\071\001\061\001\060\001\060\001\066\001\062\003ip6\004arpa", length = 34, labels = 15, attributes = 1, offsets = 0x7fea21692060 "",
buffer = 0x7fea216920e0, link = {prev = 0xffffffffffffffff, next = 0xffffffffffffffff}, list = {head = 0x0,
tail = 0x0}},
offsets = "\000\002\004\006\b\n\f\016\020\022\024\026\030\034!", '\000' <repeats 112 times>, buffer = {
magic = 1114990113, base = 0x7fea21692120, length = 255, used = 34, current = 0, active = 0, link = {
prev = 0xffffffffffffffff, next = 0xffffffffffffffff}, mctx = 0x0, autore = false},
data = "\001\061\001\060\001\060\001\060\001\061\001\060\001\071\001\061\001\060\001\060\001\066\001\062\003ip6\004arpa", '\000' <repeats 221 times>}, name = 0x7fea21692010, type = 43, options = 0, bucketnum = 133,
dbucketnum = 4294967295, info = 0x0, mctx = 0x0, now = 1644339489, task = 0x7fea285a85c0,
references = 18446744073709551615, state = fetchstate_done, want_shutdown = true, cloned = false,
spilled = false, control_event = {ev_size = 104, ev_attributes = 0, ev_tag = 0x0, ev_type = 262144,
ev_action = 0x7fea3367d90f <fctx_doshutdown>, ev_arg = 0x7fea21692000, ev_sender = 0x0, ev_destroy = 0x0,
ev_destroy_arg = 0x0, ev_link = {prev = 0xffffffffffffffff, next = 0xffffffffffffffff}, ev_ratelink = {
prev = 0xffffffffffffffff, next = 0xffffffffffffffff}}, link = {prev = 0xffffffffffffffff,
next = 0xffffffffffffffff}, events = {head = 0x0, tail = 0x0}, dfname = {name = {magic = 1145983854,
ndata = 0x7fea21692400 "", length = 1, labels = 1, attributes = 1, offsets = 0x7fea21692340 "",
buffer = 0x7fea216923c0, link = {prev = 0xffffffffffffffff, next = 0xffffffffffffffff}, list = {head = 0x0,
tail = 0x0}}, offsets = '\000' <repeats 127 times>, buffer = {magic = 1114990113, base = 0x7fea21692400,
length = 255, used = 1, current = 0, active = 0, link = {prev = 0xffffffffffffffff,
next = 0xffffffffffffffff}, mctx = 0x0, autore = false}, data = '\000' <repeats 254 times>},
domain = 0x7fea216922f0, nameservers = {magic = 1145983826, methods = 0x0, link = {prev = 0xffffffffffffffff,
next = 0xffffffffffffffff}, rdclass = 0, type = 0, ttl = 0, trust = 0, covers = 0, attributes = 0,
count = 4294967295, resign = 0, private1 = 0x0, private2 = 0x0, private3 = 0x0, privateuint4 = 0,
private5 = 0x0, private6 = 0x0, private7 = 0x0}, attributes = 392, timer = 0x0, expires = {
seconds = 1644339499, nanoseconds = 261051224}, expires_try_stale = {seconds = 0, nanoseconds = 0},
next_timeout = {seconds = 1644339496, nanoseconds = 897675111}, final = {seconds = 1644339501,
nanoseconds = 261051224}, interval = {seconds = 1, nanoseconds = 200000000}, qmessage = 0x0, queries = {
head = 0x0, tail = 0x0}, finds = {head = 0x0, tail = 0x0}, find = 0x0, altfinds = {head = 0x0, tail = 0x0},
altfind = 0x0, forwaddrs = {head = 0x0, tail = 0x0}, altaddrs = {head = 0x0, tail = 0x0}, forwarders = {
head = 0x0, tail = 0x0}, fwdpolicy = dns_fwdpolicy_only, bad = {head = 0x0, tail = 0x0}, edns = {head = 0x0,
tail = 0x0}, bad_edns = {head = 0x0, tail = 0x0}, validator = 0x0, validators = {head = 0x0, tail = 0x0},
cache = 0x0, adb = 0x0, ns_ttl_ok = false, ns_ttl = 0, qc = 0x0, minimized = false, qmin_labels = 1,
qmin_warning = ISC_R_SUCCESS, ip6arpaskip = false, forwarding = true, qminfname = {name = {magic = 1145983854,
ndata = 0x7fea216927b8 "\001\061\001\060\001\060\001\060\001\061\001\060\001\071\001\061\001\060\001\060\001\066\001\062\003ip6\004arpa", length = 34, labels = 15, attributes = 1, offsets = 0x7fea216926f8 "",
buffer = 0x7fea21692778, link = {prev = 0xffffffffffffffff, next = 0xffffffffffffffff}, list = {head = 0x0,
tail = 0x0}},
offsets = "\000\002\004\006\b\n\f\016\020\022\024\026\030\034!", '\000' <repeats 112 times>, buffer = {
magic = 1114990113, base = 0x7fea216927b8, length = 255, used = 34, current = 0, active = 0, link = {
prev = 0xffffffffffffffff, next = 0xffffffffffffffff}, mctx = 0x0, autore = false},
data = "\001\061\001\060\001\060\001\060\001\061\001\060\001\071\001\061\001\060\001\060\001\066\001\062\003ip6\004arpa", '\000' <repeats 221 times>}, qminname = 0x7fea216926a8, qmintype = 43, qminfetch = 0x0, qminrrset = {
magic = 1145983826, methods = 0x0, link = {prev = 0xffffffffffffffff, next = 0xffffffffffffffff},
rdclass = 0, type = 0, ttl = 0, trust = 0, covers = 0, attributes = 0, count = 4294967295, resign = 0,
private1 = 0x0, private2 = 0x0, private3 = 0x0, privateuint4 = 0, private5 = 0x0, private6 = 0x0,
private7 = 0x0}, qmindcfname = {name = {magic = 1145983854, ndata = 0x7fea21692a50 "", length = 1,
labels = 1, attributes = 1, offsets = 0x7fea21692990 "", buffer = 0x7fea21692a10, link = {
prev = 0xffffffffffffffff, next = 0xffffffffffffffff}, list = {head = 0x0, tail = 0x0}},
offsets = '\000' <repeats 127 times>, buffer = {magic = 1114990113, base = 0x7fea21692a50, length = 255,
used = 1, current = 0, active = 0, link = {prev = 0xffffffffffffffff, next = 0xffffffffffffffff},
mctx = 0x0, autore = false}, data = '\000' <repeats 254 times>}, qmindcname = 0x7fea21692940, pending = 0,
restarts = 1, timeouts = 0, nsfname = {name = {magic = 1145983854,
ndata = 0x7fea21692122 "\001\060\001\060\001\060\001\061\001\060\001\071\001\061\001\060\001\060\001\066\001\062\003ip6\004arpa", length = 32, labels = 14, attributes = 1, offsets = 0x7fea21692bb8 "",
buffer = 0x7fea21692c38, link = {prev = 0xffffffffffffffff, next = 0xffffffffffffffff}, list = {head = 0x0,
tail = 0x0}}, offsets = "\000\002\004\006\b\n\f\016\020\022\024\026\032\037", '\000' <repeats 113 times>,
buffer = {magic = 1114990113, base = 0x7fea21692c78, length = 255, used = 0, current = 0, active = 0, link = {
prev = 0xffffffffffffffff, next = 0xffffffffffffffff}, mctx = 0x0, autore = false},
data = '\000' <repeats 254 times>}, nsname = 0x7fea21692b68, nsfetch = 0x0, nsrrset = {magic = 1145983826,
methods = 0x0, link = {prev = 0xffffffffffffffff, next = 0xffffffffffffffff}, rdclass = 0, type = 0, ttl = 0,
trust = 0, covers = 0, attributes = 0, count = 4294967295, resign = 0, private1 = 0x0, private2 = 0x0,
private3 = 0x0, privateuint4 = 0, private5 = 0x0, private6 = 0x0, private7 = 0x0}, nqueries = 0,
rand_buf = 0, rand_bits = 0, result = ISC_R_CANCELED, vresult = ISC_R_SUCCESS, exitline = 7176, start = {
seconds = 1644339489, nanoseconds = 261051224}, duration = 12003253, logged = false, querysent = 5,
referrals = 0, lamecount = 0, quotacount = 0, neterr = 1, badresp = 1, adberr = 0, findfail = 0, valfail = 0,
timeout = false, addrinfo = 0x7fea02c8ba20, depth = 0, clientstr = "<unknown>", '\000' <repeats 53 times>}
```
</details>
And here are logs from other runs which crashed on the same line:
- [bind-run3.json.log](/uploads/5338f3dd528889677bc2201432c5799c/bind-run3.json.log)
- [bind-run5.json.log](/uploads/7aaa687521f4da04322c93cf7f248e73/bind-run5.json.log)March 2022 (9.11.37, 9.11.37-S1, 9.16.27, 9.16.27-S1, 9.18.1)Arаm SаrgsyаnArаm Sаrgsyаnhttps://gitlab.isc.org/isc-projects/bind9/-/issues/31179.18.0 nslookup debugging output2022-04-26T13:23:59ZJohn E. Krokes9.18.0 nslookup debugging output
### Summary
nslookup in interactive mode produces debugging output by default
### BIND version used
BIND 9.18.0 (Stable Release) <id:8db45af>
running on Linux x86_64 5.10.0-11-amd64 #1 SMP Debian 5.10.92-1 (2022-01-18)
built by make ...
### Summary
nslookup in interactive mode produces debugging output by default
### BIND version used
BIND 9.18.0 (Stable Release) <id:8db45af>
running on Linux x86_64 5.10.0-11-amd64 #1 SMP Debian 5.10.92-1 (2022-01-18)
built by make with '--sysconfdir=/etc' '--localstatedir=/var' '--disable-linux-caps' '--disable-doh'
compiled by GCC 10.2.1 20210110
compiled with OpenSSL version: OpenSSL 1.1.1k 25 Mar 2021
linked to OpenSSL version: OpenSSL 1.1.1k 25 Mar 2021
compiled with libuv version: 1.40.0
linked to libuv version: 1.40.0
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
threads support is enabled
default paths:
named configuration: /etc/named.conf
rndc configuration: /etc/rndc.conf
DNSSEC root key: /etc/bind.keys
nsupdate session key: /var/run/named/session.key
named PID file: /var/run/named/named.pid
named lock file: /var/run/named/named.lock
### Steps to reproduce
run nslookup
attempt to look up literally anything
### What is the current *bug* behavior?
debugging output is produced alongside expected output
### What is the expected *correct* behavior?
normal output
### Possible fixes
in bin/dig/nslookup.c
Line 624 is "debugging = true;".
I suggest that this should be either "debugging = false;" or the line should be deleted.March 2022 (9.11.37, 9.11.37-S1, 9.16.27, 9.16.27-S1, 9.18.1)https://gitlab.isc.org/isc-projects/bind9/-/issues/3112[CVE-2022-0396] DoS in BIND via lingering TCP sockets stuck in CLOSE-WAIT2022-04-21T08:06:51ZDan Theisen[CVE-2022-0396] DoS in BIND via lingering TCP sockets stuck in CLOSE-WAIT<!--
THIS ISSUE TEMPLATE IS INTENDED ONLY FOR INTERNAL USE.
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 - the...<!--
THIS ISSUE TEMPLATE IS INTENDED ONLY FOR INTERNAL USE.
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).
-->
An issue in BIND can consume TCP connection slots indefinitely via a specifically crafted TCP stream sent by a client.
https://wiki.isc.org/bin/view/Main/SecurityIncident202201TCPStuckInCloseWaitDoS
### CVE-specific actions
- [x] Assign a CVE identifier: CVE-2022-0396
- [x] Determine CVSS score: 4.9 total (5.3 base), CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L/E:F/RL:O/RC:C
- [x] Determine the range of BIND versions affected (including the Subscription Edition)
- [x] Determine whether workarounds for the problem exists
- Issue can be mitigated by setting `keep-repsonse-order { "none"; };`
- [x] Create a draft of the security advisory and put the information above in there
- https://mattermost.isc.org/isc/channels/cve-2022-0396-dos-lingering-tcp-sockets/hyt7spw4dpnpf89nfra5htuexy
- [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)
- The configuration option `keep-response-order { "any"; };` must be set on the server.
- A script which reproduces the issue is attached [I-root-19872-linger-repro_bind-9.16.py](/uploads/283b5c088abfc60312e0378a1899b88c/I-root-19872-linger-repro_bind-9.16.py)
- Client opens TCP socket with server with SO_LINGER sockopt set to >0
- Client must send at least ONE properly formed query to the server
- Client sends any additional garbage to server over socket
- Client closes socket and walks away
- Connection on server side stays in CLOSE-WAIT indefinitely
- https://gitlab.isc.org/isc-projects/bind9/-/issues/3112#note_265790
- [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)
- https://gitlab.isc.org/isc-private/bind9/-/merge_requests/354
- a fix for the issue
- documentation updates (`CHANGES`, release notes, anything else applicable)
- https://gitlab.isc.org/isc-private/bind9/-/merge_requests/353
- [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](isc-private/bind9#49)
- [x] [Reserve a block of `CHANGES` placeholders once the complete set of vulnerabilities fixed in a given release cycle is determined](!5925)
- [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 branchesMarch 2022 (9.11.37, 9.11.37-S1, 9.16.27, 9.16.27-S1, 9.18.1)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/3092Add keyfromlabel system test2022-02-25T13:11:42ZMatthijs Mekkingmatthijs@isc.orgAdd keyfromlabel system testMarch 2022 (9.11.37, 9.11.37-S1, 9.16.27, 9.16.27-S1, 9.18.1)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/2950[CVE-2021-25220] DNS Cache Poisoning Vulnerability2022-11-10T08:15:18ZOndřej Surý[CVE-2021-25220] DNS Cache Poisoning Vulnerability### CVE-specific actions
- [x] Assign a CVE identifier: CVE-2021-25220
- [x] Determine CVSS score: [6.8](https://mattermost.isc.org/isc/pl/esax9emkd7fxdxqxm99zaz9azw): CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:N/I:H/A:N/E:U/RL:U/RC:C
- ...### CVE-specific actions
- [x] Assign a CVE identifier: CVE-2021-25220
- [x] Determine CVSS score: [6.8](https://mattermost.isc.org/isc/pl/esax9emkd7fxdxqxm99zaz9azw): CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:N/I:H/A:N/E:U/RL:U/RC:C
- [x] Determine the range of BIND [versions affected](https://gitlab.isc.org/isc-projects/bind9/-/issues/2950#note_243838) (including the Subscription Edition)
- [x] Determine whether [workarounds](https://gitlab.isc.org/isc-projects/bind9/-/issues/2950#note_243853) for the problem exists: No
- [x] Create a draft of the security advisory and put the information above in there (+ add [credits](https://gitlab.isc.org/isc-projects/bind9/-/issues/2950#note_244651))
- [x] Prepare a detailed description of the problem which should include the following by default:
- instructions for [reproducing the problem](https://gitlab.isc.org/isc-projects/bind9/-/issues/2950#note_243791) (a system test is good enough)
- explanation of [code flow](https://gitlab.isc.org/isc-projects/bind9/-/issues/2950#note_244624) which triggers the problem (a system test is *not* good enough)
- [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 maintained [+ this time also v9.11](https://gitlab.isc.org/isc-projects/bind9/-/issues/2950#note_243881)) 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](isc-private/bind9#49)
- [x] [Reserve a block of `CHANGES` placeholders once the complete set of vulnerabilities fixed in a given release cycle is determined](!5925)
- [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
# Report: DNS Cache Poisoning Vulnerability
By Xiang Li from Network and Information Security Laboratory, Tsinghua University
On Oct 10, 2021
## Overview
We found a vulnerability in the bailiwick checking procedure of your resolver, which allows specific attackers to inject NS records of any domain (even TLDs) into the cache and conduct a DNS cache poisoning attack. The effects of an exploit would be widespread and highly impactful, as this injection could hijack any subdomain under the poisoned domain, including TLDs, e.g., com and net .
## Vulnerability Details
When the resolver is configured with a conditional forwarding zone and a forwarder, it will query all domains under the zone targeting the forwarder. For example, we give a brief config file in the following, where queries of any domain under `attacker.com` will be sent directly to `x.x.x.x` for resolution. While for the other domains, they are processed by the resolver itself through recursive queries, such as `com` and `victim.com`.
```
options {
recursion yes;
dnssec-validation yes; // this is not sufficient to enable DNSSEC validation - keys are missing!
};
zone "attacker.com" {
type forward;
forwarders { x.x.x.x port 53; };
};
```
If an attacker query A records of `x.attacker.com`, and the resolver receives a response with an AA flag in the following. The bogus `NS` records of com will be cached. As a result, queries of any domain under `com` in the future will be sent directly to the fake name server `ns.attacker.com`, thus hijacked by attackers.
| Field | Value |
|------------|---------------------------|
| Question | x.attacker.com A |
| Answer | x.attacker.com A 1.2.3.4 |
| Authority | com NS ns.attacker.com |
## Root Cause Analysis
Through source code review, we locate the root cause of the vulnerability.
Specifically, `Query.zone` is the key to bailiwick checking logic. Any resource records whose name is not under or same as `Query.zone` during responses processing will be removed.
However, when forwarding, `Query.zone` is initialized with the "closest" name of NS records following the recursive resolution process.
As for the forwarding zone, there are no directly corresponding `NS` records. Therefore, for example, when querying `attacker.com`, `Query.zone` is com or the root `.`.
Consequently, the fake domain is under `com` and `.`, which is considered to be in-bailiwick.
## Proof-of-Concept
We give two exploiting methods and show our real attack videos in the [link](https://cloud.tsinghua.edu.cn/d/faddf16c281e41a7b216/) with password: `bind_attack_pre_21`.
For ethical considerations, we build the whole DNS testing environment, including the attacker machine, the conditional DNS server, the upstream resolver, and our authoritative server. And we use `attacker.attack` as an example domain to attack NS records of `com`.
1. If the forwarder `x.x.x.x` is held by an attacker, he can return the bogus response directly from the authoritative server. We show our attack steps below, and the video is named `bind_attack_fd.mp4` in the folder.
1. From 00:00, we show the latest BIND version.
2. From 00:05, we start BIND.
3. From 00:10, we query `github.com` and obtain correct `com` `NS` records through recursive queries.
4. From 00:20, we query the forwarded domain `attacker.attack` and receive fake com `NS` records.
5. From 00:28, bingo, fake `com` `NS` records are cached successfully.
2. If the forwarder `x.x.x.x` is not held by an attacker, he should inject the bogus response directly from the off-path. And we leverage the SAD DNS attack to poison the resolver successfully. We show our attack steps below, and the video is named `bind_attack_fu.mp4` in the folder.
1. From 00:00, we show the latest BIND version and Linux version.
2. From 00:06, we start BIND.
3. From 00:11, we query `github.com` and obtain correct `com` `NS` records through recursive queries.
4. From 00:21, we query the forwarded domain `[random_prefix].attacker.attack` and start [SAD DNS](https://www.saddns.net/) attacks.
5. From 33:10, bingo, after 1,642 attempts costing 1,970s, fake `com` `NS` records are cached successfully.
## Threat Surface
We test the latest version 9.16.21, until Oct. 10, 2021, which is vulnerable.
## Mitigation
Consider setting Query.zone with the forwarding zone, such as attacker.com .
## Attachments
* [Report_-_DNS_Cache_Poisoning_Vulnerability_of_BIND.pdf](/uploads/f7e07b5bf026bec7f875dea6fd4f9b42/Report_-_DNS_Cache_Poisoning_Vulnerability_of_BIND.pdf)March 2022 (9.11.37, 9.11.37-S1, 9.16.27, 9.16.27-S1, 9.18.1)Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/2802Fix missed occurrences of renaming masters to primaries2022-03-01T11:39:16ZMatthijs Mekkingmatthijs@isc.orgFix missed occurrences of renaming masters to primariesIssue #1992 dealt with renaming `masters` to `primaries`.
Ondrej noticed there are some leftover occurrences: https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/5234#note_223058
Fix this occurrence and review if we missed others.Issue #1992 dealt with renaming `masters` to `primaries`.
Ondrej noticed there are some leftover occurrences: https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/5234#note_223058
Fix this occurrence and review if we missed others.March 2022 (9.11.37, 9.11.37-S1, 9.16.27, 9.16.27-S1, 9.18.1)https://gitlab.isc.org/isc-projects/bind9/-/issues/2717Fix sysconfdir path in man pages with hardcoded default paths2022-02-25T13:57:06ZAthos RibeiroFix sysconfdir path in man pages with hardcoded default pathsSome man pages have hardcoded values for the default configuration file paths.
This path is configurable through the `sysconfdir` variable, and the manpages
should perform the proper substitutions whenever the default value is changed.
...Some man pages have hardcoded values for the default configuration file paths.
This path is configurable through the `sysconfdir` variable, and the manpages
should perform the proper substitutions whenever the default value is changed.
This attached patch (**which applies against the `v9_16` branch**) uses the
already existing template system for building the docs toperform such
substitutions.
[0004-fix-sysconfdir-path-in-man-pages.patch](/uploads/f1029c9d28f49f6f0179d18914d20c16/0004-fix-sysconfdir-path-in-man-pages.patch)March 2022 (9.11.37, 9.11.37-S1, 9.16.27, 9.16.27-S1, 9.18.1)