News, tips, advice, support for Windows, Office, PCs & more. Tech help. No bull. We're community supported by donations from our Plus Members, and proud of it
Home icon Home icon Home icon Email icon RSS icon
  • FAQ: The Windows DNS Server security hole, CVE-2020-1350, from a “normal” user’s perspective

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

    • This topic has 21 replies, 10 voices, and was last updated 2 weeks ago.
    Viewing 12 reply threads
    • Author
      Posts
      • #2280657 Reply
        woody
        Da Boss

        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.
      • #2280671 Reply
        Microfix
        AskWoody MVP

        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.

        | Win8.1 Pro x64 | Linux Hybrids x86/x64 | Win7 Pro x86/x64 Offline |
        4 users thanked author for this post.
        • #2281037 Reply
          Marcus Weldby
          AskWoody Plus

          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.

          • #2282439 Reply
            Marcus Weldby
            AskWoody Plus

            Does anyone know the answer to this question?

            • #2282451 Reply
              anonymous
              Guest

              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.
        • #2281365 Reply
          Microfix
          AskWoody MVP

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

          | Win8.1 Pro x64 | Linux Hybrids x86/x64 | Win7 Pro x86/x64 Offline |
      • #2280669 Reply
        anonymous
        Guest

        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?

        • #2280679 Reply
          anonymous
          Guest

          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.
        • #2280844 Reply
          woody
          Da Boss

          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.
        • #2281046 Reply
          blackbox
          AskWoody Plus

          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.

      • #2280688 Reply
        dph853
        AskWoody Plus

        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?

        • #2280692 Reply
          PKCano
          Da Boss

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

          3 users thanked author for this post.
      • #2280693 Reply
        anonymous
        Guest

        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…

        • #2280890 Reply
          anonymous
          Guest

          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.

      • #2280697 Reply
        BKS_CB
        AskWoody Plus

        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.

        • #2280699 Reply
          Microfix
          AskWoody MVP

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

          | Win8.1 Pro x64 | Linux Hybrids x86/x64 | Win7 Pro x86/x64 Offline |
          2 users thanked author for this post.
        • #2280702 Reply
          woody
          Da Boss

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

          1 user thanked author for this post.
          • #2280711 Reply
            BKS_CB
            AskWoody Plus

            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?

            • #2280712 Reply
              Microfix
              AskWoody MVP

              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.

              | Win8.1 Pro x64 | Linux Hybrids x86/x64 | Win7 Pro x86/x64 Offline |
              2 users thanked author for this post.
      • #2280843 Reply
        Mr. Natural
        AskWoody Plus

        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 reporting from the front lines.

        3 users thanked author for this post.
        • #2281027 Reply
          Mr. Natural
          AskWoody Plus

          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 reporting from the front lines.

          2 users thanked author for this post.
      • #2280929 Reply
        NetDef
        AskWoody_MVP

        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.
      • #2281573 Reply
        Tchalms
        AskWoody Plus

        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?

        • #2281590 Reply
          NetDef
          AskWoody_MVP

          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" ~

        • #2281600 Reply
          NetDef
          AskWoody_MVP

          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:

          prereqwarning

          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.

          Might_work

          success
          (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 2 weeks, 6 days ago by NetDef.
          • This reply was modified 2 weeks, 6 days ago by NetDef.
          Attachments:
          • #2281606 Reply
            NetDef
            AskWoody_MVP

            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:

            failed

            Once it recovered, the Update history shows:

            failed2

            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" ~

            Attachments:
      • #2281628 Reply
        Paul T
        AskWoody MVP

        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

      • #2281757 Reply
        Tchalms
        AskWoody Plus

        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 !!

      • #2282745 Reply
        whatsyournameagain4
        AskWoody Plus

        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?

      • #2282900 Reply
        Tchalms
        AskWoody Plus

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

    Viewing 12 reply threads

    Please follow the -Lounge Rules- no personal attacks, no swearing, and politics/religion are relegated to the Rants forum.

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

    You can use BBCodes to format your content.
    Your account can't use Advanced BBCodes, they will be stripped before saving.