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

[Lee]

On 8/17/21, Viktor Dukhovni <ietf-dane at dukhovni.org> wrote:
>> 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.

Seems to me that for all practical purposes, we're disagreeing about
if it will happen.

I'd like it fixed today -- which I can do with a bit of collateral
damage by enabling check-names.

If I wait for all the programmers to fix their buggy implementations/
make the correct library calls I'll be waiting forever.

If I wait for all the libraries to add validation .. what's your guess
for how many years that will take?

Regards,
Lee

> * 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.