[dns-operations] Injection Attacks Reloaded: Tunnelling Malicious Payloads over DNS

Viktor Dukhovni ietf-dane at dukhovni.org
Tue Aug 17 23:40:02 UTC 2021


> On 17 Aug 2021, at 7:27 pm, Lee <ler762 at gmail.com> wrote:
> 
>> I am far from convinced that it is the resolvers job to enforce RDATA
>> syntax restrictions beyond what is required for a valid wire form.
>> 
>> If applications make unwarranted assumptions about the syntax of
>> DNS replies, that's surely an application bug, rather than an issue
>> in DNS.
> 
> I disagree.  Programmers f**k up _all the time_
>  https://www.microsoft.com/en-us/securityengineering/sdl/about
>    "In January 2002, Microsoft launched its Trustworthy Computing
> initiative to help ensure Microsoft products and services were built
> inherently highly secure, available, reliable..."
> 
> M$ is still shipping buggy software; blaming programmers hasn't helped.

We're only disagreeing about where the validation belongs, not whether
it should happen.

* An iterative resolver is definitely not the place to censor results
  based on value syntax.

* A general-purpose stub resolver that supports general (qname, type)
  queries would likewise IMHO not be a good place to do that.

* Once we get closer to the application, say getaddrinfo(3) with AI_CANONNAME,
  it is perhaps then reasonable for the C library to fail the lookup when
  the name is deemed invalid.

* But ideally, there should higher-layer validating APIs for the application
  to use, with the base APIs focused on reliably returning accurate data.

Do not open-code validation at the call sites, employ existing or write new
validating wrappers.  Tools can check that unsafe APIs aren't used outside
the modules that are doing the validation.

-- 
	Viktor.





More information about the dns-operations mailing list