Fix resolver assertion failure due to improper DNAME handling (CVE-2016-1286) (#41753)

(cherry picked from commit 5995fec51c)
This commit is contained in:
Mukund Sivaraman 2016-02-22 12:22:43 +05:30
parent a372b927ed
commit 456e1eadd2
3 changed files with 29 additions and 15 deletions

View file

@ -1,3 +1,7 @@
4319. [security] Fix resolver assertion failure due to improper
DNAME handling when parsing fetch reply messages.
(CVE-2016-1286) [RT #41753]
4318. [security] Malformed control messages can trigger assertions
in named and rndc. (CVE-2016-1285) [RT #41666]

View file

@ -77,6 +77,13 @@
#41666]
</para>
</listitem>
<listitem>
<para>
The resolver could abort with an assertion failure due to
improper DNAME handling when parsing fetch reply
messages. This flaw is disclosed in CVE-2016-1286. [RT #41753]
</para>
</listitem>
</itemizedlist>
</section>

View file

@ -6981,21 +6981,26 @@ answer_response(fetchctx_t *fctx) {
isc_boolean_t found_dname = ISC_FALSE;
dns_name_t *dname_name;
/*
* Only pass DNAME or RRSIG(DNAME).
*/
if (rdataset->type != dns_rdatatype_dname &&
(rdataset->type != dns_rdatatype_rrsig ||
rdataset->covers != dns_rdatatype_dname))
continue;
/*
* If we're not chaining, then the DNAME and
* its signature should not be external.
*/
if (!chaining && external) {
log_formerr(fctx, "external DNAME");
return (DNS_R_FORMERR);
}
found = ISC_FALSE;
aflag = 0;
if (rdataset->type == dns_rdatatype_dname) {
/*
* We're looking for something else,
* but we found a DNAME.
*
* If we're not chaining, then the
* DNAME should not be external.
*/
if (!chaining && external) {
log_formerr(fctx,
"external DNAME");
return (DNS_R_FORMERR);
}
found = ISC_TRUE;
want_chaining = ISC_TRUE;
POST(want_chaining);
@ -7024,9 +7029,7 @@ answer_response(fetchctx_t *fctx) {
&fctx->domain)) {
return (DNS_R_SERVFAIL);
}
} else if (rdataset->type == dns_rdatatype_rrsig
&& rdataset->covers ==
dns_rdatatype_dname) {
} else {
/*
* We've found a signature that
* covers the DNAME.