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

    Home » Forums » Newsletter and Homepage topics » FAQ: The Windows DNS Server security hole, CVE-2020-1350, from a “normal” user’s perspective

    Author
    Topic
    #2280657

    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.
    Viewing 11 reply threads
    Author
    Replies
    • #2280671

      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.
      • #2281037

        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.
        • #2282439

          Does anyone know the answer to this question?

          • #2282451

            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

        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...
    • #2280669

      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

        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

        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

        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

      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

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

        3 users thanked author for this post.
    • #2280693

      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

        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

      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

        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.
      • #2280702

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

        1 user thanked author for this post.
        • #2280711

          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

            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.
    • #2280843

      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.
      • #2281027

        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.
    • #2280929

      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

      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

        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

        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 4 years, 10 months ago by NetDef.
        • This reply was modified 4 years, 10 months ago by NetDef.
        • #2281606

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

    • #2281628

      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

      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

      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

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

    Viewing 11 reply threads
    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 all available BBCodes, they will be stripped before saving.

    Your information: