Commit a6ecb58f authored by Vladimír Čunát's avatar Vladimír Čunát Committed by Petr Špaček

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).
parent 6576904c
......@@ -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) {
......
......@@ -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);
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment