[CVE-2022-3094] An UPDATE message flood may cause named to exhaust all available memory

Quick Links	🔗
Incident Manager:	@pspacek
Deputy Incident Manager:	@peterd
Public Disclosure Date:	2023-01-25
CVSS Score:	7.5
Security Advisory:	isc-private/printing-press!41
Mattermost Channel:	CVE-2022-3094 UPDATE flood memory exhaustion
Support Ticket:	https://support.isc.org/Ticket/Display.html?id=21126
Release Checklist:	#3755 (closed)
Post-mortem Etherpad:	postmortem-2023-01

💡 Click here (internal resource) for general information about the security incident handling process.

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 of CHANGES 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

• 🔗 (Support) Verify that all ASN-eligible customers have received the notification email

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

---

Reported to us via Support Ticket #21126

Reported against BIND 9.16.23

named consumes available memory and is killed by Linux's OOM killer when
it receives a flood of DNS UPDATEs.

This appears to be a regression due to the netmgr changes in recent
branches of BIND. In BIND 9.11 which our older appliance branches use, the
client code automatically rate-limited itself and would not go to read new
requests (ns_client_next()) from the listening socket when it had not
responded to the client object's existing request. It also ran within a
client task. This construct and automatic rate-limiting is gone in the
netmgr design where queries are continually delivered to
ns__client_request() by netmgr.

DNS UPDATEs are handled by ns_update_start(), which queues an event to
execute update_action() within the zone's task, and returns to the
client code which cleans up and moves to the next request. When
update_action() is not fast enough vs. incoming DNS UPDATEs,
update_action() events queue up and exhaust available memory.

Via ns__client_request():

* recursions use quota
* xfrouts use quota
* DNS UPDATE processing and forwarding are unlimited
* incoming notifies appear to be limited within notify processing in
  lib/dns/zone.c

To fix this bug in our appliance, we have added quota to send_update_event()
and send_forward_event() to limit the number of events in-flight.

The following is an extract of patch with the relevant changes just in
lib/ns/update.c; the full patch is not shared as it modifies a lot of
the appliance BIND code. Let us know if you're not able to follow the issue
and/or the patch.

See also #3588 (closed)