FAQ: The Windows DNS Server security hole, CVE-2020-1350, from a “normal” user’s perspective

Topic

New Reply

You’re going to see a lot of sand flying about a Windows security hole that was plugged yesterday. Here’s what most people need to know about CVE-2020
[See the full post at: FAQ: The Windows DNS Server security hole, CVE-2020-1350, from a “normal” user’s perspective]

4 users thanked author for this post.

abbodi86, Elly, CyGuy, geekdom

Reply | Quote

Replies

more info on the registry edit from the horses mouth:
https://support.microsoft.com/en-us/help/4569509/windows-dns-server-remote-code-execution-vulnerability

Workaround

To work around this vulnerability, make the following registry change to restrict the size of the largest inbound TCP-based DNS response packet allowed:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters

TcpReceivePacketSize

Value = 0xFF00

Note You must restart the DNS Service for the registry change to take effect.

The Default (also max) Value = 0xFFFF
The Recommended Value = 0xFF00 (255 bytes less than the max)

After the workaround is implemented, a Windows DNS server will be unable to resolve DNS names for its clients when the DNS response from the upstream server is larger than 65280 bytes.

Windows - commercial by definition and now function...

4 users thanked author for this post.

NetDef, Mr. Natural, geekdom, woody

Reply | Quote

[Marcus Weldby]

I did the TcpReceivePacketSize registry edit on my 2008R2 server, and I also installed KB4565540 on my 2012R2 server. After the reboot I’m not seeing a TcpReceivePacketSize  entry on my 2012R2 server, does the KB4565540 update solve the DNS issue a different way?

Thank you.

• This reply was modified 4 years, 11 months ago by Marcus Weldby.

Reply | Quote

Does anyone know the answer to this question?

Reply | Quote

FAQs in the guidance document recommend removing the registry workaround after a server has been patched, so the patch must solve the underlying issue rather than rely on the temporary packet size restriction.

1 user thanked author for this post.

Marcus Weldby

Reply | Quote

More info on SigRed over on SANS with some additional info that may be of use i.e. ‘suricata rule’

Windows - commercial by definition and now function...

Reply | Quote

It’s not stated in Microsoft KB, is this TcpReceivePacketSize key a String or DWORD type? And if DWORD, to you just put FF00 in value field?

Reply | Quote

It’s a DWORD. The value should be entered as 00FF00 if you’re doing it through the GUI.

2 users thanked author for this post.

NetDef, woody

Reply | Quote

I have independent confirmation of the anonymous post above.

It’s a DWORD, #00FF00, even tho the KB article says #FF00.

2 users thanked author for this post.

NetDef, Elly

Reply | Quote

With 2 confirmations I feel like I may be missing something here, but with the value being a DWORD, I’d assume a hex value of FF00 or a decimal value of 65280 would be the expected values entered via GUI.

Reply | Quote

So if I understand correctly those running simple Windows 10 v1909 or similar do not need to worry about this bug. Only those running a version of windows server and specifically a DNS service for their internal network are at risk. Correct?

Reply | Quote

Simple Windows 10 v1909 or similar do not need to worry about this vulnerability.

3 users thanked author for this post.

Elly, dph853, woody

Reply | Quote

All our DNS servers are Server 2008 R2, and after doing a sync on our WSUS server, I don’t see any of the applicable patches showing up…. So I guess I’m leaning towards the reg tweak for now…

Reply | Quote

Server 2008 R2 has been out of support since January. You have no other option but the registry workaround, but you need to make plans to upgrade your servers as soon as you can.

Reply | Quote

Given that this is a security vulnerability present for 17 years, before SBS2011 (2008 R2) EOL; is Microsoft allowing KB4565524 to be applied even if the server is not Extended Service Updates?

Thanks in advance.

Reply | Quote

MS patched XP when it was out of support for the ‘Wannacry/Eternalblue’ exploits..given that action I would certainly hope so.

Windows - commercial by definition and now function...

2 users thanked author for this post.

BKS_CB, woody

Reply | Quote

Like @Microfix, I hope so – but I’m not going to hold my breath.

1 user thanked author for this post.

BKS_CB

Reply | Quote

We are using 0patch on our Win7 systems & 2008 R2 based servers. Great support & pleased with the service.

Anyway, guess for the servers the ‘workaround’ is the best choice for us at the moment?

Reply | Quote

If it’s a published microsoft, article I would think so.
0Patch will probably issue something also given the severity of the potential. Perhaps implement the workaround in preperation for 0Patch or Microsoft, whichever lands first.

Windows - commercial by definition and now function...

2 users thanked author for this post.

woody, BKS_CB

Reply | Quote

All of our DNS servers are 2012r2. I was able to update and reboot one of them today and the rest of them will be updated after hours this evening. I don’t foresee any issues but if I do I will follow up on this post tomorrow. If you don’t hear back then I would say no issues to report with the DNS server patches.

All other updates are on hold of course, for now.

Red Ruffnsore

3 users thanked author for this post.

Kobold Curry Chef, NetDef, Microfix

Reply | Quote

I had no issues updating all servers overnight. Including the .net patches and the IE11 update for 2012r2. This includes 2012r2, 2016, and 2019 servers. All dns servers updated.

Disclaimer – your mileage may vary.

Red Ruffnsore

2 users thanked author for this post.

Kobold Curry Chef, Microfix

Reply | Quote

My team patched many servers early this morning, none had issues.  Even our notoriously cranky Server 2016 machines patched quickly and easily this time around.

 

~ Group "Weekend" ~

2 users thanked author for this post.

Kobold Curry Chef, Microfix

Reply | Quote

For those with Server 2008 R2 ( asking for “a friend” ) I’m wondering about updates from MS.

Can someone please verify what I think I found, or did I make a mistake connecting the dots?

This article:
https://support.microsoft.com/en-us/help/4569509/windows-dns-server-remote-code-execution-vulnerability

Led me to this article:
https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-1350

Which includes a table of articles and updates for every server from 2008 to 2019 and the Core Servers up to 2004.

The links in the table lead to the Microsoft Update Catalog and buttons to download the update.

What is the correct procedure for installing one of these updates?

Reply | Quote

I saw that too, and wish I had an old Server 2008 R2 to play with still.  My guess is that it would manually update from the download fine.  Uncertain I would want to test on a production server.  Then again, if you have a 2008 R2 production server, try it, and it fails . . . it might be the kick needed to upgrade. 

 

 

Wait a minute . . . I have a HyperV image backup of an old 2008 R2 from a couple years ago from a retired machine.  Stand by.

~ Group "Weekend" ~

Reply | Quote

[NetDef]

That was a fun ride.

Spun up an orphaned HyperV image of an old Server 2008 R2 application server.  I want to emphasize this is a pretty plain-jane server config:  It does NOT have any advanced roles like Active Directory / Domain Controller installed.  It was a print and application server only.  Also of note is I let Windows Update catch it up to January 2020 before the following experiment.

1) Downloaded the MSU via Catalog link for Server 2008 R2 listed at: https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-1350

2) Tried to install it and failed with this message:

Note: Clicking that blue link in the error took me to a VERY outdated Microsoft page, which subsequently led down a rabbit hole of obsolete downloads for Service Stack editions dating circa 2011 . . . (in other words, don’t bother!)

3) Circled around and found the Server 2008 R2 July 2020 Service stack update for ESU customers at http://www.catalog.update.microsoft.com/Search.aspx?q=KB4565354 and successfully installed that. (Note: I do not have ESU on this machine, nor was ESU simulated per other sources available on this site.)

4) After that step, I was able to successfully install the July 2020 Rollup on this machine.

(It did provide a success message, but that window didn’t include the KB number.)

Remember class, this was NOT on a production server – after this test I shut it down and relegated the HyperV image back to storage. All disclaimers apply here.

TL:DR – it appears Microsoft is not blocking this update for Server 2008 R2.

But – it failed on reboot (see next message)

~ Group "Weekend" ~

• This reply was modified 4 years, 11 months ago by NetDef.
• This reply was modified 4 years, 11 months ago by NetDef.

Reply | Quote

So I had a thought and went to spin that HyperV machine back up to check on something — and it’s a good thing I did!  It powered up on the second phase install of the July Rollup and presented me with this:

Once it recovered, the Update history shows:

I suspect either a per-requisite patch after Jan 2020 is missing (in spite of the fact that roll-ups are supposed to include that stuff) OR this patch doesn’t check ESU status until the reboot – which is playing nasty since this is openly available on the Microsoft Catalog.

If I have time will dig deeper in a few days.

~ Group "Weekend" ~

Reply | Quote

Tchalms wrote:

For those with Server 2008 R2 ( asking for “a friend” )

A reminder: if the server isn’t in an AD network or doesn’t run DNS server it doesn’t need the update.

cheers, Paul

Reply | Quote

Paul T wrote:

Tchalms wrote:

For those with Server 2008 R2 ( asking for “a friend” )

A reminder: if the server isn’t in an AD network or doesn’t run DNS server it doesn’t need the update.

cheers, Paul

PaulT: Yeah, a client has had serious budget troubles and couldn’t do the server upgrade last year … then came Covid. They are running AD and DNS Server. I have done the Registry edit.

NetDef: Thanks for the efforts and info !!

Reply | Quote

I was dumb enough to do the registry change on my normal Windows 10 Pro machine, and now I have trouble remembering what the default value should be, or if the string should even be there. Does anyone know what it should be? Is it FFFF?

Reply | Quote

The registry change involved creating the new key and giving it that value. I would just delete that key.

Reply | Quote