Case: NSEC3 with too many iterations used for a positive wildcard proof.
To really fix the answers, this also needed fixing the `any_rank` part
which I somehow forgot in commit
7107faebc :-(
Knot Resolver 5.3.2 (2021-0m-dd)
================================
+Security
+--------
+- validator: fix 5.3.1 regression on over-limit NSEC3 edge case (!1169)
+ Assertion might be triggered by query/answer, potentially DoS.
+
Improvements
------------
- cache: improve handling write errors from LMDB (!1159)
if (rrset->type != KNOT_RRTYPE_NSEC3) {
continue;
}
+ if (knot_nsec3_iters(rrset->rrs.rdata) > KR_NSEC3_MAX_ITERATIONS) {
+ /* Avoid hashing with too many iterations.
+ * If we get here, the `sname` wildcard probably ends up bogus,
+ * but it gets downgraded to KR_RANK_INSECURE when validator
+ * gets to verifying one of these over-limit NSEC3 RRs. */
+ continue;
+ }
int ret = covers_name(&flags, rrset, sname);
if (ret != 0) {
return ret;
* KNOT_ERANGE - NSEC3 RR that covers a wildcard
* has been found, but has opt-out flag set;
* otherwise - error.
+ * Records over KR_NSEC3_MAX_ITERATIONS are skipped, so you probably get kr_error(ENOENT).
*/
int kr_nsec3_wildcard_answer_response_check(const knot_pkt_t *pkt, knot_section_t section_id,
const knot_dname_t *sname, int trim_to_next);
bailiwick) < 0) {
continue;
}
- if (kr_rank_test(entry->rank, KR_RANK_INITIAL)
+ if (any_rank
+ || kr_rank_test(entry->rank, KR_RANK_INITIAL)
|| kr_rank_test(entry->rank, KR_RANK_TRY)
|| kr_rank_test(entry->rank, KR_RANK_MISSING)) {
kr_rank_set(&entry->rank, rank_to_set);
-Subproject commit 01eabd23dc3315ef9d27ae7f5fe19c142dcbdfdb
+Subproject commit c4628156e6cf499e8052c321b24793a176ded494