lib/cache: don't stash packets with zeros in QNAME

Cache uses dname_lf for keys, i.e. zero bytes serve as separators
between labels.  Therefore having a zero inside label could masquerade
for QNAME that does have label separators instead of these zeros.
That doesn't seem really exploitable in practice, as standard registries
won't allow such labels, so I can't see any possible attack that would
"cross border" of these registries, e.g. attacking anything inside
example.org without any cooperation from its owner (or org or root).

diff --git a/lib/cache/api.c b/lib/cache/api.c
index 795755f628d055e9c9d8c8780467cb3f307a3b54..bb7560ec9aa32f012fc1d23cb12b08549302ffab 100644 (file)
--- a/lib/cache/api.c
+++ b/lib/cache/api.c
@@ -414,7 +414,9 @@ int cache_stash(kr_layer_t *ctx, knot_pkt_t *pkt)
        /* LATER(optim.): typically we also have corresponding NS record in the list,
         * so we might save a cache operation. */
 
-       stash_pkt(pkt, qry, req, needs_pkt);
+       if (check_dname_for_lf(knot_pkt_qname(pkt), qry)) {
+               stash_pkt(pkt, qry, req, needs_pkt);
+       }
 
 finally:
        if (unauth_cnt) {

diff --git a/lib/cache/impl.h b/lib/cache/impl.h
index c016c452d751a19805ae2035a43477392c9007a5..6afd389a46ee7baeda517e9b6aee699a5eb55906 100644 (file)
--- a/lib/cache/impl.h
+++ b/lib/cache/impl.h
@@ -265,7 +265,8 @@ void entry_list_memcpy(struct entry_apex *ea, entry_list_t list);
 
 /** Stash the packet into cache (if suitable, etc.)
  * \param needs_pkt we need the packet due to not stashing some RRs;
- *             see stash_rrset() for details */
+ *             see stash_rrset() for details
+ * It assumes check_dname_for_lf(). */
 void stash_pkt(const knot_pkt_t *pkt, const struct kr_query *qry,
                const struct kr_request *req, bool needs_pkt);