[dns-operations] Wormable RCE in MS Windows DNS Server CVE-2020-1350

[Brian Somers]

On Jul 20, 2020, at 2:08 PM, Tony Finch <dot at dotat.at> wrote:
> 
> Alexander Bochmann <ab at lists.gxis.de> wrote:
>> 
>> Would other nameservers drop a reply where this scheme with pointer
>> compression resulting in a very large Signer's Name field is
>> being used? It doesn't look invalid as such.
> 
> Name compression isn't allowed in SIG / RRSIG / NSEC, which are the
> records that can be used to trigger this bug. A server would be justified
> to drop responses with compressed names in the wrong place, but I don't
> know how strict other implementations are in practice.

Name compression isn’t allowed in RRSIG or NSEC but it is allowed in SIG.

RFC 3597 section 4 backtracks on this a little and suggests that resolvers
SHOULD decompress SIG (and others) because it was a mistake to allow
it to be compressed in the first place.

The same section reiterates that [name?] servers MUST NOT compress
domain names embedded in the RDATA of types that are class-specific
and not well-known… and goes on to define well-known to not include
SIG.

So, a resolver that drops or decompresses compressed SIG RRs should
protect windows, assuming windows doesn’t just go ahead and ask the
authority directly.

Having said all of that, there’s also another issue…. In the past, ecfr.gov/A
nameservers responded to queries with the DO bit with an RRSIG that had
a compressed signer field.  This seemed to be tolerated by the mainstream
resolvers and I ended up adding a configuration option to ours to allow it.
Although that seems to have been fixed now, it does make me question how
much of the original SIG parsing code (that allows compressed signers)
survives in modern day resolver decoding of RRSIG RRs.

In short, resolvers should disallow compressed RRSIG signers (and may not),
should decompress SIG signers before regurgitating them to a client, and
should probably never actually serve them in the first place unless maybe as
part of an ANY response (I would argue that a response that contains all SIGs
for all types for a given name is not useful to anybody).  If the uncompressed
SIG overflows the response data to more than 64k, SERVFAIL should be
returned to the client.

Well, that’s how I see it anyway...

—
Brian