[dns-operations] Injection Attacks Reloaded: Tunnelling Malicious Payloads over DNS
ietf-dane at dukhovni.org
Tue Aug 17 20:42:59 UTC 2021
> On 17 Aug 2021, at 4:17 pm, Tony Finch <dot at dotat.at> wrote:
> So I don't think the problems can be dismissed as simply application bugs:
> the problems come from mismatches in expectations at the boundary between
> the DNS and the applications. And the DNS is notorious (the subject of
> memes!) for being far too difficult to use correctly.
I remain unconvinced. The DNS-library's job is to accurately return
the DNS query payload to the application. If the application further
expects some particular syntax, then it needs to check for that, e.g.:
valid_hostname() scrutinizes a hostname: the name should
be no longer than VALID_HOSTNAME_LEN characters, should
contain only letters, digits, dots and hyphens, no adjacent
dots, no leading or trailing dots or hyphens, no labels
longer than VALID_LABEL_LEN characters, and it should not
be all numeric.
valid_utf8_hostname() is a wrapper around valid_hostname().
If EAI support is compiled in, and enable_utf8 is true, the
name is converted from UTF-8 to ASCII per IDNA rules, before
dns_lookup() looks up DNS resource records. When requested to
look up data other than type CNAME, it will follow a limited
number of CNAME indirections. All result names (including
null terminator) will fit a buffer of size DNS_NAME_LEN.
All name results are validated by \fIvalid_hostname\fR();
an invalid name is reported as a DNS_INVAL result, while
malformed replies are reported as transient errors.
This is not particularly different from other sorts of input validation
needed to avoid SQL injection attacks, shell command injection attacks,
and so forth.
$ git grep -Ecw 'valid(_utf8)?_hostname' 'src/*.c' | sort -t: -k2nr
More information about the dns-operations