Fix CVE-2022-3080
5960. [security] Fix serve-stale crash that could happen when stale-answer-client-timeout was set to 0 and there was a stale CNAME in the cache for an incoming query. (CVE-2022-3080) [GL #3517] Resolves: CVE-2022-3080
This commit is contained in:
parent
f05e2e34bd
commit
e69de99fb9
116
bind-9.16-CVE-2022-3080.patch
Normal file
116
bind-9.16-CVE-2022-3080.patch
Normal file
@ -0,0 +1,116 @@
|
||||
From 3bcd32572504ac9b92e3c6ec1e2cee3df3b68309 Mon Sep 17 00:00:00 2001
|
||||
From: Petr Mensik <pemensik@redhat.com>
|
||||
Date: Tue, 20 Sep 2022 11:34:42 +0200
|
||||
Subject: [PATCH 2/4] Fix CVE-2022-3080
|
||||
|
||||
5960. [security] Fix serve-stale crash that could happen when
|
||||
stale-answer-client-timeout was set to 0 and there was
|
||||
a stale CNAME in the cache for an incoming query.
|
||||
(CVE-2022-3080) [GL #3517]
|
||||
---
|
||||
lib/ns/include/ns/query.h | 1 +
|
||||
lib/ns/query.c | 42 ++++++++++++++++++++++++---------------
|
||||
2 files changed, 27 insertions(+), 16 deletions(-)
|
||||
|
||||
diff --git a/lib/ns/include/ns/query.h b/lib/ns/include/ns/query.h
|
||||
index 4d48cf6..34b3070 100644
|
||||
--- a/lib/ns/include/ns/query.h
|
||||
+++ b/lib/ns/include/ns/query.h
|
||||
@@ -145,6 +145,7 @@ struct query_ctx {
|
||||
bool authoritative; /* authoritative query? */
|
||||
bool want_restart; /* CNAME chain or other
|
||||
* restart needed */
|
||||
+ bool refresh_rrset; /* stale RRset refresh needed */
|
||||
bool need_wildcardproof; /* wildcard proof needed */
|
||||
bool nxrewrite; /* negative answer from RPZ */
|
||||
bool findcoveringnsec; /* lookup covering NSEC */
|
||||
diff --git a/lib/ns/query.c b/lib/ns/query.c
|
||||
index 249321c..a450cb7 100644
|
||||
--- a/lib/ns/query.c
|
||||
+++ b/lib/ns/query.c
|
||||
@@ -5686,7 +5686,6 @@ query_lookup(query_ctx_t *qctx) {
|
||||
bool dbfind_stale = false;
|
||||
bool stale_timeout = false;
|
||||
bool stale_found = false;
|
||||
- bool refresh_rrset = false;
|
||||
bool stale_refresh_window = false;
|
||||
|
||||
CCTRACE(ISC_LOG_DEBUG(3), "query_lookup");
|
||||
@@ -5868,8 +5867,7 @@ query_lookup(query_ctx_t *qctx) {
|
||||
"%s stale answer used, an attempt to "
|
||||
"refresh the RRset will still be made",
|
||||
namebuf);
|
||||
- refresh_rrset = STALE(qctx->rdataset);
|
||||
- qctx->client->nodetach = refresh_rrset;
|
||||
+ qctx->refresh_rrset = STALE(qctx->rdataset);
|
||||
}
|
||||
} else {
|
||||
/*
|
||||
@@ -5907,17 +5905,6 @@ query_lookup(query_ctx_t *qctx) {
|
||||
|
||||
result = query_gotanswer(qctx, result);
|
||||
|
||||
- if (refresh_rrset) {
|
||||
- /*
|
||||
- * If we reached this point then it means that we have found a
|
||||
- * stale RRset entry in cache and BIND is configured to allow
|
||||
- * queries to be answered with stale data if no active RRset
|
||||
- * is available, i.e. "stale-anwer-client-timeout 0". But, we
|
||||
- * still need to refresh the RRset.
|
||||
- */
|
||||
- query_refresh_rrset(qctx);
|
||||
- }
|
||||
-
|
||||
cleanup:
|
||||
return (result);
|
||||
}
|
||||
@@ -7737,11 +7724,14 @@ query_addanswer(query_ctx_t *qctx) {
|
||||
|
||||
/*
|
||||
* On normal lookups, clear any rdatasets that were added on a
|
||||
- * lookup due to stale-answer-client-timeout.
|
||||
+ * lookup due to stale-answer-client-timeout. Do not clear if we
|
||||
+ * are going to refresh the RRset, because the stale contents are
|
||||
+ * prioritized.
|
||||
*/
|
||||
if (QUERY_STALEOK(&qctx->client->query) &&
|
||||
- !QUERY_STALETIMEOUT(&qctx->client->query))
|
||||
+ !QUERY_STALETIMEOUT(&qctx->client->query) && !qctx->refresh_rrset)
|
||||
{
|
||||
+ CCTRACE(ISC_LOG_DEBUG(3), "query_clear_stale");
|
||||
query_clear_stale(qctx->client);
|
||||
/*
|
||||
* We can clear the attribute to prevent redundant clearing
|
||||
@@ -11457,9 +11447,29 @@ ns_query_done(query_ctx_t *qctx) {
|
||||
/*
|
||||
* Client may have been detached after query_send(), so
|
||||
* we test and store the flag state here, for safety.
|
||||
+ * If we are refreshing the RRSet, we must not detach from the client
|
||||
+ * in the query_send(), so we need to override the flag.
|
||||
*/
|
||||
+ if (qctx->refresh_rrset) {
|
||||
+ qctx->client->nodetach = true;
|
||||
+ }
|
||||
nodetach = qctx->client->nodetach;
|
||||
query_send(qctx->client);
|
||||
+
|
||||
+ if (qctx->refresh_rrset) {
|
||||
+ /*
|
||||
+ * If we reached this point then it means that we have found a
|
||||
+ * stale RRset entry in cache and BIND is configured to allow
|
||||
+ * queries to be answered with stale data if no active RRset
|
||||
+ * is available, i.e. "stale-anwer-client-timeout 0". But, we
|
||||
+ * still need to refresh the RRset. To prevent adding duplicate
|
||||
+ * RRsets, clear the RRsets from the message before doing the
|
||||
+ * refresh.
|
||||
+ */
|
||||
+ message_clearrdataset(qctx->client->message, 0);
|
||||
+ query_refresh_rrset(qctx);
|
||||
+ }
|
||||
+
|
||||
if (!nodetach) {
|
||||
qctx->detach_client = true;
|
||||
}
|
||||
--
|
||||
2.37.3
|
||||
|
@ -51,7 +51,7 @@ Summary: The Berkeley Internet Name Domain (BIND) DNS (Domain Name System) serv
|
||||
Name: bind
|
||||
License: MPLv2.0
|
||||
Version: 9.16.23
|
||||
Release: 4%{?dist}
|
||||
Release: 5%{?dist}
|
||||
Epoch: 32
|
||||
Url: https://www.isc.org/downloads/bind/
|
||||
#
|
||||
@ -105,6 +105,7 @@ Patch171:bind-9.11-tests-variants.patch
|
||||
Patch172:bind-9.16-CVE-2022-0396.patch
|
||||
Patch173:bind-9.16-CVE-2021-25220.patch
|
||||
Patch174:bind-9.16-CVE-2021-25220-test.patch
|
||||
Patch175:bind-9.16-CVE-2022-3080.patch
|
||||
|
||||
%{?systemd_ordering}
|
||||
Requires: coreutils
|
||||
@ -408,6 +409,7 @@ in HTML and PDF format.
|
||||
%patch172 -p1 -b .CVE-2022-0396
|
||||
%patch173 -p1 -b .CVE-2021-25220
|
||||
%patch174 -p1 -b .CVE-2021-25220-test
|
||||
%patch175 -p1 -b .CVE-2022-3080
|
||||
|
||||
%if %{with PKCS11}
|
||||
%patch135 -p1 -b .config-pkcs11
|
||||
@ -1130,6 +1132,9 @@ fi;
|
||||
%endif
|
||||
|
||||
%changelog
|
||||
* Thu Sep 22 2022 Petr Menšík <pemensik@redhat.com> - 32:9.16.23-5
|
||||
- Fix possible serve-stale related crash (CVE-2022-3080)
|
||||
|
||||
* Thu Jul 14 2022 Petr Menšík <pemensik@redhat.com> - 32:9.16.23-4
|
||||
- Export bind-doc package (#2104863)
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user