dns response handling: ignore presence of wrong-type RRs
authorRich Felker <dalias@aerifal.cx>
Wed, 19 Oct 2022 17:15:11 +0000 (13:15 -0400)
committerRich Felker <dalias@aerifal.cx>
Wed, 19 Oct 2022 18:01:32 +0000 (14:01 -0400)
commit41603c7706f8a4c1b1a2a23e49ff7490f6860dc2
tree776eaac7aee3c08580ab3faafdbffd06c39229f6
parentcf76df0e1fe09b0d504ca650fdaa01df5bf9ab72
dns response handling: ignore presence of wrong-type RRs

reportedly there is nameserver software with question-rewriting
"functionality" which gives A answers when AAAA is queried. since we
made no effort to validate that the answer RR type actually
corresponds to the question asked, it was possible (depending on
flags, etc.) for these answers to leak through, which the caller might
not be prepared for. indeed, our implementation of gethostbyname2_r
makes an assumption that the resulting addresses are in the family
requested, and will misinterpret the results if they don't.

commit 45ca5d3fcb6f874bf5ba55d0e9651cef68515395 already noted in
fixing CVE-2017-15650 that this could happen, but did nothing to
validate that the RR type of the answer matches the question; it just
enforced the limit on number of results to preclude overflow.

presently, name_from_dns ignores the return value of __dns_parse, so
it doesn't really matter whether we return 0 (ignoring the RR) or -1
(parse-ending error) upon encountering the mismatched RR. if that ever
changes, though, ignoring irrelevant answer RRs sounds like the
semantically correct thing to do, so for now let's return 0 from the
callback when this happens.
src/network/lookup_name.c