[CVE-2022-3736] named configured to answer from stale cache may terminate unexpectedly while processing RRSIG queries
Quick Links | |
---|---|
Incident Manager: | @michal |
Deputy Incident Manager: | @peterd |
Public Disclosure Date: | 2023-01-25 |
CVSS Score: | 7.5 |
Security Advisory: | isc-private/printing-press!36 |
Mattermost Channel: | CVE-2022-3736 RRSIG query crash |
Support Ticket: | N/A |
Release Checklist: | #3755 (closed) |
Post-mortem Etherpad: | postmortem-2023-01 |
Earlier Than T-5
-
🔗 (IM) Pick a Deputy Incident Manager -
🔗 (IM) Respond to the bug reporter -
🔗 (IM) Create an Etherpad for post-mortem -
🔗 (SwEng) Ensure there are no public merge requests which inadvertently disclose the issue -
🔗 (IM) Assign a CVE identifier -
🔗 (SwEng) Update this issue with the assigned CVE identifier and the CVSS score -
🔗 (SwEng) Determine the range of product versions affected (including the Subscription Edition) -
🔗 (SwEng) Determine whether workarounds for the problem exist -
🔗 (SwEng) If necessary, coordinate with other parties -
🔗 (Support) Prepare and send out "earliest" notifications -
🔗 (Support) Create a merge request for the Security Advisory and include all readily available information in it -
🔗 (SwEng) Prepare a private merge request containing a system test reproducing the problem -
🔗 (SwEng) Notify Support when a reproducer is ready -
🔗 (SwEng) Prepare a detailed explanation of the code flow triggering the problem -
🔗 (SwEng) Prepare a private merge request with the fix -
🔗 (SwEng) Ensure the merge request with the fix is reviewed and has no outstanding discussions -
🔗 (Support) Review the documentation changes introduced by the merge request with the fix -
🔗 (SwEng) Prepare backports of the merge request addressing the problem for all affected (and still maintained) branches of a given product -
🔗 (Support) Finish preparing the Security Advisory -
🔗 (QA) Create (or update) the private issue containing links to fixes & reproducers for all CVEs fixed in a given release cycle -
🔗 (QA) (BIND 9 only) Reserve a block ofCHANGES
placeholders once the complete set of vulnerabilities fixed in a given release cycle is determined -
🔗 (QA) Merge the CVE fixes in CVE identifier order -
🔗 (QA) Prepare a standalone patch for the last stable release of each affected (and still maintained) product branch -
🔗 (QA) Prepare ASN releases (as outlined in the Release Checklist)
At T-5
-
🔗 (Support) Send ASN to eligible customers -
🔗 (Support) (BIND 9 only) Send a pre-announcement email to the bind-announce mailing list to alert users that the upcoming release will include security fixes
At T-4
At T-1
-
🔗 (Support) Verify that any new or reinstated customers have received the notification email -
🔗 (First IM) Send notifications to OS packagers
On the Day of Public Disclosure
-
🔗 (IM) Grant Support clearance to proceed with public release -
🔗 (Support) Publish the releases (as outlined in the release checklist) -
🔗 (Support) (BIND 9 only) Update vulnerability matrix in the Knowledge Base -
🔗 (Support) Bump Document Version for the Security Advisory and publish it in the Knowledge Base -
🔗 (First IM) Send notification emails to third parties -
🔗 (First IM) Advise MITRE about the disclosed CVEs -
🔗 (First IM) Merge the Security Advisory merge request -
🔗 (IM) Inform original reporter (if external) that the security disclosure process is complete -
🔗 (Support) Inform customers a fix has been released
After Public Disclosure
-
🔗 (First IM) Organize post-mortem meeting and make sure it happens -
🔗 (Support) Close support tickets -
🔗 (QA) Merge a regression test reproducing the bug into all affected (and still maintained) branches
Summary
BIND 9.16.33 crashes with type != ((dns_rdatatype_t)dns_rdatatype_rrsig)
BIND version used
BIND 9.16.33 (Extended Support Version) <id:35e9c6e>
running on FreeBSD amd64 13.1-RELEASE FreeBSD 13.1-RELEASE fc952ac22 DNS13
built by make with '--disable-linux-caps' '--localstatedir=/var' '--sysconfdir=/usr/local/etc/namedb' '--with-dlopen=yes' '--without-python' '--with-libxml2' '--with-openssl=/usr' '--with-readline=-L/usr/local/lib -ledit' '--with-dlz-filesystem=yes' '--enable-dnstap' '--disable-fixed-rrset' '--disable-geoip' '--without-maxminddb' '--without-gssapi' '--with-libidn2=/usr/local' '--without-json-c' '--disable-largefile' '--with-lmdb=/usr/local' '--disable-native-pkcs11' '--disable-querytrace' '--enable-tcp-fastopen' '--enable-developer' '--enable-symtable' '--prefix=/usr/local' '--mandir=/usr/local/man' '--infodir=/usr/local/share/info/' '--build=amd64-portbld-freebsd13.1' 'build_alias=amd64-portbld-freebsd13.1' 'CC=cc' 'CFLAGS=-pipe -DLIBICONV_PLUG -g -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing ' 'LDFLAGS= -fstack-protector-strong ' 'LIBS=-L/usr/local/lib' 'CPPFLAGS=-DLIBICONV_PLUG -isystem /usr/local/include' 'CPP=cpp' 'PKG_CONFIG=pkgconf' 'PKG_CONFIG_LIBDIR=/usr/ports/dns/bind916/work/.pkgconfig:/usr/local/libdata/pkgconfig:/usr/local/share/pkgconfig:/usr/libdata/pkgconfig'
compiled by CLANG FreeBSD Clang 13.0.0 (git@github.com:llvm/llvm-project.git llvmorg-13.0.0-0-gd7b669b3a303)
compiled with OpenSSL version: OpenSSL 1.1.1o-freebsd 3 May 2022
linked to OpenSSL version: OpenSSL 1.1.1o-freebsd 3 May 2022
compiled with libuv version: 1.44.2
linked to libuv version: 1.44.2
compiled with libxml2 version: 2.9.13
linked to libxml2 version: 20913
compiled with zlib version: 1.2.12
linked to zlib version: 1.2.12
compiled with protobuf-c version: 1.4.1
linked to protobuf-c version: 1.4.1
threads support is enabled
default paths:
named configuration: /usr/local/etc/namedb/named.conf
rndc configuration: /usr/local/etc/namedb/rndc.conf
DNSSEC root key: /usr/local/etc/namedb/bind.keys
nsupdate session key: /var/run/named/session.key
named PID file: /var/run/named/pid
named lock file: /var/run/named/named.lock
Steps to reproduce
Can't reproduce but seems to be related to the stale answer cache.
The first time it happened it affected two recursive servers using the stale answer cache feature. In order to check whether it happened again I disabled stale answer cache on one of them and, surprise, it has happened again only on the server that had stale answer cache still enabled.
What is the current bug behavior?
A crash due to an assert.
What is the expected correct behavior?
(What you should see instead.)
Relevant configuration files
(Paste any relevant configuration files - please use code blocks (```)
to format console output. If submitting the contents of your
configuration file in a non-confidential Issue, it is advisable to
obscure key secrets: this can be done automatically by using
named-checkconf -px
.)
Relevant logs and/or screenshots
#0 thr_kill () at thr_kill.S:4
#1 0x0000000800dd6c74 in __raise (s=s@entry=6)
at /usr/src/lib/libc/gen/raise.c:52
#2 0x0000000800e88109 in abort () at /usr/src/lib/libc/stdlib/abort.c:67
#3 0x000000000030c3d0 in assertion_failed (file=0x2a9b3e "db.c", line=524,
type=isc_assertiontype_require,
cond=0x2857d1 "type != ((dns_rdatatype_t)dns_rdatatype_rrsig)")
at ./main.c:271
#4 0x0000000000675c5d in isc_assertion_failed (file=0x2a9b3e "db.c",
line=524, type=isc_assertiontype_require,
cond=0x2857d1 "type != ((dns_rdatatype_t)dns_rdatatype_rrsig)")
at assertions.c:48
#5 0x00000000003e2b02 in dns_db_findext (db=0x8024c2400, name=0x81e6c0900,
version=0x0, type=46, options=6152, now=1666651564, nodep=0x7fffdffed120,
foundname=0x84d1f4c00, methods=0x7fffdffec770, clientinfo=0x7fffdffecbc0,
rdataset=0x84ce32f80, sigrdataset=0x0) at db.c:524
#6 0x000000000037e51d in query_lookup (qctx=0x7fffdffecc90) at query.c:5793
#7 0x000000000039c66d in query_lookup_stale (client=0x84d1f8d58)
at query.c:6034
#8 0x000000000037f61b in fetch_callback (task=0x809fcf480, event=0x82b875400)
at query.c:6076
#9 0x00000000006c6d08 in task_run (task=0x809fcf480) at task.c:851
#10 0x00000000006c68e5 in isc_task_run (task=0x809fcf480) at task.c:944
--Type <RET> for more, q to quit, c to continue without paging--
#11 0x00000000006a2e95 in isc__nm_async_task (worker=0x8016f0000,
ev0=0x83a2aba00) at netmgr.c:861
#12 0x000000000069b00b in process_netievent (worker=0x8016f0000,
ievent=0x83a2aba00) at netmgr.c:933
#13 0x00000000006a2c3a in process_queue (worker=0x8016f0000,
type=NETIEVENT_TASK) at netmgr.c:999
#14 0x00000000006a27ff in process_all_queues (worker=0x8016f0000)
at netmgr.c:780
#15 0x0000000000696f74 in async_cb (handle=0x8016f02d8) at netmgr.c:809
#16 0x0000000800cd16bf in uv__async_io (loop=0x8016f0010, w=0x8016f0188,
events=1) at src/unix/async.c:163
#17 0x0000000800cee489 in uv__io_poll (loop=0x8016f0010, timeout=-1)
at src/unix/kqueue.c:390
#18 0x0000000800cd1d5b in uv_run (loop=0x8016f0010, mode=UV_RUN_DEFAULT)
at src/unix/core.c:406
#19 0x0000000000696fdd in nm_thread (worker0=0x8016f0000) at netmgr.c:711
#20 0x00000000006ca51f in isc__trampoline_run (arg=0x80161b690)
at trampoline.c:213
#21 0x0000000800d0983a in thread_start (curthread=0x801612e00)
at /usr/src/lib/libthr/thread/thr_create.c:292
#22 0x0000000000000000 in ?? ()
The coredump and binaries are located on the bikeshed: /home/support/named-crash-borjam-20221025.tar.gz