From c1190a3fe0e9a204bd748322b1dddb32801122b9 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Mon, 1 Mar 2021 16:46:07 +1100 Subject: [PATCH 1/3] Handle DNAME lookup via itself When answering a query, named should never attempt to add the same RRset to the ANSWER section more than once. However, such a situation may arise when chasing DNAME records: one of the DNAME records placed in the ANSWER section may turn out to be the final answer to a client query, but there is no way to know that in advance. Tweak the relevant INSIST assertion in query_respond() so that it handles this case properly. qctx->rdataset is freed later anyway, so there is no need to clean it up in query_respond(). --- lib/ns/query.c | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/lib/ns/query.c b/lib/ns/query.c index 97b8a9d5a2..f15101ced2 100644 --- a/lib/ns/query.c +++ b/lib/ns/query.c @@ -8173,10 +8173,16 @@ query_respond(query_ctx_t *qctx) { query_addnoqnameproof(qctx); /* - * We shouldn't ever fail to add 'rdataset' - * because it's already in the answer. + * 'qctx->rdataset' will only be non-NULL here if the ANSWER section of + * the message to be sent to the client already contains an RRset with + * the same owner name and the same type as 'qctx->rdataset'. This + * should never happen, with one exception: when chasing DNAME records, + * one of the DNAME records placed in the ANSWER section may turn out + * to be the final answer to the client's query, but we have no way of + * knowing that until now. In such a case, 'qctx->rdataset' will be + * freed later, so we do not need to free it here. */ - INSIST(qctx->rdataset == NULL); + INSIST(qctx->rdataset == NULL || qctx->qtype == dns_rdatatype_dname); query_addauth(qctx); From a2954c3b5749c55861e71a07470a5c4e27a7dbda Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Mon, 1 Mar 2021 16:09:39 +1100 Subject: [PATCH 2/3] Add CHANGES entry for [GL #2540] --- CHANGES | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/CHANGES b/CHANGES index 2798122996..6619a41975 100644 --- a/CHANGES +++ b/CHANGES @@ -43,7 +43,9 @@ 5617. [placeholder] -5616. [placeholder] +5616. [security] named crashed when a DNAME record placed in the ANSWER + section during DNAME chasing turned out to be the final + answer to a client query. (CVE-2021-25215) [GL #2540] 5615. [security] Insufficient IXFR checks could result in named serving a zone without an SOA record at the apex, leading to a From f1d81d4e89fdca2fba1552e16a6ab45d72bb487c Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Mon, 1 Mar 2021 16:08:21 +1100 Subject: [PATCH 3/3] Add Release Notes entry for [GL #2540] --- doc/notes/notes-current.rst | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/doc/notes/notes-current.rst b/doc/notes/notes-current.rst index b559bccf92..ca8344ac80 100644 --- a/doc/notes/notes-current.rst +++ b/doc/notes/notes-current.rst @@ -20,6 +20,15 @@ Security Fixes ISC would like to thank Greg Kuechle of SaskTel for bringing this vulnerability to our attention. [GL #2467] +- ``named`` crashed when a DNAME record placed in the ANSWER section + during DNAME chasing turned out to be the final answer to a client + query. (CVE-2021-25215) + + ISC would like to thank `Siva Kakarla`_ for bringing this + vulnerability to our attention. [GL #2540] + +.. _Siva Kakarla: https://github.com/sivakesava1 + Known Issues ~~~~~~~~~~~~