Patch Now and Remediation for Microsoft CVE-2020-1350 DNS vulnerability

Note that if you use the registry key workaround, you’ll need to restart the DNS service for the change to take effect (or reboot the server).

Our blog post on the vulnerability:

HUGE shoutout to @Nic for posting this first in the other communities a lot of us follow and huge shoutout to Ottomocks in general for being super quick to send out an email on it. Awesome effort spreading the word - you guys probably saved thousands of DNS servers!

Thanks - there’s a big team of us that put this together every month (or whenever out of band critical patches go out): @Richard @fdysart @molly @taylor.teets @Chris.Hass

It truly takes a village to raise a DNS server, as Hillary Clinton taught us 🙂

Wired’s hot take:

Microsoft Warns of a 17-Year-Old ‘Wormable’ Bug

The SigRed vulnerability exists in Windows DNS, used by practically every small and medium-sized organization in the world.

That PS code doesn’t seem to work correctly. Here’s my script tested locally directly on a MS DNS server:

Set registry:

New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\DNS\Parameters"   TcpReceivePacketSize -Type DWORD -Value 0xFF00 -Force

Restart DNS:

Restart-Service -Name DNS

May have to set execution policy:

set-executionpolicy remotesigned

Issue with original script from post is that there is no “type” parameter for the “Set-ItemProperty”

Confirmed that the powershell command suggested in OP does not work on a 2016 box. Also confirming that ElevenB2003’s assessment is correct and that their script works. The DNS service restart is icing on the cake.

Thanks for catching that @ElevenB2003 - I must have been testing my code on a machine that I’d already created the registry key for, so I didn’t catch that I needed to use New instead of Set. You get both the bug finder badge and the coder badge for fixing and improving my code!

Note: I’ve edited my original post to include @ElevenB2003’s working script instead of my bogus one.

Glad to help!

Thanks!

Here’s the technical details behind the exploit:

It was indeed a large packet generating a buffer overflow as we’d guessed from the workaround. The workaround sets a max packet size that the DNS service will accept, which is why it stops this trick from working.

Nice response guys; managed to patch all our DCs lastnight. ‘Ottomocks’ is a life-savior. 🙂

1.6GB for the patch seems pretty significant so don’t put off the patch by using the reg entry for too long. Install the patch afterwards and remove the reg then.

Feds are saying 24 hour mandate for all government agencies to roll out this patch:

Some people on reddit are reporting issues with patching on some domain controllers with the July batch of patches: