Micropatch Available for "SIGRed", the Wormable Remote Code Execution in Windows DNS Server (CVE-2020-1350)

by Mitja Kolsek, the 0patch Team

This month's Patch Tuesday included a fix for CVE-2020-1350, a critical memory corruption vulnerability in Windows DNS Server affecting all Windows Server versions from long-unsupported Server 2003 to the latest Server 2019.

After Microsoft's initial announcement and security advisory, the CheckPoint research team published a detailed article about the issue, describing the attack vector and providing enough information for other security researchers to trigger the vulnerability. Just one day later, the first real proof-of-concept was published, developed by Max Van Amerongen (@maxpl0it) from F-Secure Labs, and later several other researchers have shown their own tools triggering the vulnerability.

We can safely assume that offensive teams worldwide are currently trying to develop a reliable arbitrary code execution exploit as they know that Windows Updates take anywhere from long to eternity before getting applied to most Windows Servers out there. Their job will not be trivial, with various exploit mitigations in place on modern Windows servers, but counting on them to fail would be a risky strategy. In addition, many companies are still using Windows Server 2008 machines with no security updates past January this year.

Numerous 0patch customers have one or more Windows 2008 Servers and we wanted to take care of them as quickly as possible. With a working proof-of-concept at hand we could easily create a micropatch for this issue. Let's look at Microsoft's patch first:

 

The image above shows the difference between vulnerable function SigWireRead (left) and its patched counterpart (right). This function was one of only three functions in dns.exe modified by the July update, and the other two were not relevant for the issue at hand.

Microsoft's patch (gray code blocks) introduced three integer overflow/underflow checks, for one subtraction and two addition operations. When faced with Max's proof-of-concept, it is the third check (the lowest gray code block) that detects the overflow and redirects execution towards function's exit instead of processing the DNS packet further - which would lead to memory corruption. 

Our micropatch does logically the same, with one difference - when integer overflow/underflow is detected, it also displays and logs an exploit attempt, allowing admins to know that their server was targeted by an exploit:

MODULE_PATH "..\Affected_Modules\dns.exe_6.1.7601.24437_64bit\dns.exe"
PATCH_ID 456
PATCH_FORMAT_VER 2
VULN_ID 6390
PLATFORM win64

patchlet_start
    PATCHLET_ID 1
    PATCHLET_TYPE 2
    PATCHLET_OFFSET 0x4EC89
    N_ORIGINALBYTES 5
    JUMPOVERBYTES 0
    PIT dns.exe!0x4EC68
   
    code_start
        push rdi ; push to ensure normal code flow after patch
        push rax ; push to ensure normal code flow after patch
       
        ;First check
        sub rdi, rax
        cmp rdi, 0xFFFF
        ja ExploitBlocked ; the TCP packet is not valid, jump to Exploit Blocked
       
        ;Second check
        movzx eax, byte[rsp+30h+2*8] ; added 2*8 to the original offset to compensate for the 2 pushes at the beginning
        add ax, 0x14
        cmp ax, 0x12
        jb ExploitBlocked ; the TCP packet is not valid, jump to Exploit Blocked
       
        ;Third check
        lea ecx, [rax+rdi]
        cmp cx, ax
        jb ExploitBlocked ; the TCP packet is not valid, jump to Exploit Blocked
        jmp End ; the TCP packet is valid, continue with original code
    ExploitBlocked:
        pop rax ; restore rax to its previous value
        pop rdi ; restore rdi to its previous value
        call PIT_ExploitBlocked ; Exploit Blocked pop up
        jmp PIT_0x4EC68 ; Exit function, TCP packet not valid
    End:
        pop rax ; restore rax to its previous value
        pop rdi ; restore rdi to its previous value
    code_end
   
patchlet_end

We released our micropatch early afternoon CET today and it got applied to all online computers with 0patch PRO worldwide within 60 minutes without restarting the computer or DNS service.

This is how it looks like when a DNS server is attacked without and with 0patch:

The first instance of our micropatch is targeted at Windows Server 2008 R2 without Extended Security Updates, and we plan to port it to Windows Server 2003 next for our users who are for various reasons still using this unsupported server. [Update 7/20/2020: Micropatch is now ported to 32-bit and 64-bit Windows Server 2003.]

Although free official updates exist for all supported Windows servers, admins may not be able to apply them immediately or restart the computer; for such cases, requests for porting our micropatch to specific versions of dns.exe running on affected computers can be sent to sales@0patch.com.

If you have 0patch Agent with PRO license installed on your Windows Server 2008 R2 or Server 2003 computer, our micropatch is already downloaded and applied to your DNS server. Otherwise, to obtain the micropatch and have it applied on your computer(s) along with other micropatches included with a PRO license, create an account in 0patch Central, purchase a PRO license or request a trial at sales@0patch.com, install 0patch Agent and register it to your account.

Note that no computer restart is needed for installing the agent or applying/un-applying any 0patch micropatch.

To learn more about 0patch, please visit our Help Center.

We'd like to thank Max Van Amerongen (@maxpl0it) from F-Secure Labs for publishing their analysis and POC, and for providing additional assistance in triggering the vulnerability and simplifying our test case, thereby allowing us to create this micropatch for Windows users without official security updates.

Micropatch is Available for Memory Corruption in DHCP Message Processing (CVE-2020-0662)

by Mitja Kolsek, the 0patch Team

Windows 7 and Server 2008 R2 users without Extended Security Updates have just received a micropatch for CVE-2020-0662, a remote memory corruption vulnerability in DHCP message processing.

This vulnerability was patched by Microsoft with February 2020 Updates, but Windows 7 and Server 2008 users without Extended Security Updates remained vulnerable.

Security researcher Spencer McIntyre (@zeroSteiner) analyzed this vulnerability and published a POC, from which we could reproduce the issue and create a micropatch.

The vulnerability lies in accepting a hardware address in a DHCP packet that is longer than 20h bytes, resulting in out-of-bounds read or write, depending on the Windows version. Our micropatch is logically identical to Microsoft's: it adds a check for the HW address length:

MODULE_PATH "..\Affected_Modules\ipnathlp.dll"
PATCH_ID 454
PATCH_FORMAT_VER 2
VULN_ID 5909
PLATFORM win64

patchlet_start
    PATCHLET_ID 1
    PATCHLET_TYPE 2
    PATCHLET_OFFSET 0x1AB45
    N_ORIGINALBYTES 5
    JUMPOVERBYTES 0
    PIT ipnathlp.dll!0x1AB94   
   
    ; Added check for Hardware address length, must be <= 20
   
    code_start
        mov al, [rsi+0xE6] ; [rsi+0xE6] = value of hardware address length
        cmp al, 0x20 ; compare hardware address length with 0x20
        jbe RestoreCodeFlow ; jump if hradware address length is <= 20
        call PIT_ExploitBlocked ; exploit blocked shown if hardware address length is > 20
        call GetText ; get address for Error text
        db 'DhcpProcessMessage: ignoring message since HWAdderLength is greater than MAX_HARDWARE_ADDRESS_LENGTH',0 ; Error message
    GetText:
        pop rdx ; set rdx to error code address like MS org patch
        jmp PIT_0x1AB94 ; jump to ensure same code flow like MS patch
    RestoreCodeFlow:
    code_end
   
patchlet_end

We'd like to thank Spencer McIntyre (@zeroSteiner) for sharing their analysis and POC, and for additional assistance in reproducing the bug, which allowed us to create this micropatch for Windows users without official security updates.

This micropatch is immediately available to all 0patch users with a PRO license, and is targeted at Windows 7 and Windows Server 2008 R2 users without Extended Security Updates. To obtain the micropatch and have it applied on your computer(s) along with other micropatches included with a PRO license, create an account in 0patch Central, install 0patch Agent and register it to your account. Note that no computer restart is needed for installing the agent or applying/un-applying any 0patch micropatch.

To learn more about 0patch, please visit our Help Center.

Remote Code Execution Vulnerability in Zoom Client for Windows (0day)

by Mitja Kolsek, the 0patch Team

[Update 7/13/2020: Zoom only took one (!) day to issue a new version of Client for Windows that fixes this vulnerability, which is remarkable. We have reviewed their fix and can confirm that it efficiently resolves the vulnerability. With an official vendor fix available to all users, we made our micropatches for this issue PRO-only according to our guidelines. Meanwhile, after issuing micropatches for this issue targeted at Zoom Client for Windows versions 5.0.3 to 5.1.2, we noticed a lot of our users being on all of these versions despite Zoom's highly persistent update mechanism. We had expected most users to be on version 5.1.2., but this indicates many users may still be on even older Zoom Client versions. We therefore ported our micropatch to the remaining supported versions of Zoom Client: 5.0.0., 5.0.1, and 5.0.2. We're now covering all vulnerable supported clients.]

Earlier this week a security researcher shared a remote code execution "0day" vulnerability in Zoom Client for Windows with our team. The vulnerability allows a remote attacker to execute arbitrary code on victim's computer where Zoom Client for Windows (any currently supported version) is installed by getting the user to perform some typical action such as opening a document file. No security warning is shown to the user in the course of attack.

The researcher (who wants to keep their identity private) stated that they did not report the vulnerability to Zoom either directly or through a broker, but would not object to us reporting it to Zoom.

Analysis

We analyzed the issue and determined it to be only exploitable on Windows 7 and older Windows systems. While Microsoft's official support for Windows 7 has ended this January, there are still millions of home and corporate users out there prolonging its life with Microsoft's Extended Security Updates or with 0patch.

We then documented the issue along with several attack scenarios, and reported it to Zoom earlier today along with a working proof of concept and recommendations for fixing. Should a bug bounty be awarded by Zoom, it shall be waived in favor of a charity of researcher's choice.

Micropatch

On the micropatching side, we were able to quickly create a micropatch that removes the vulnerability in four different places in the code. The micropatch was then ported from the latest version of Zoom Client for Windows (5.1.2) to previous five versions back to 5.0.3 released on May 17, 2020. Zoom Client features a fairly persistent auto-update functionality that is likely to keep home users updated unless they really don't want to be. However, enterprise admins often like to keep control of updates and may stay a couple of versions behind, especially if no security bugs were fixed in the latest versions (which is currently the case).

Our micropatches have already been released and distributed to all online 0patch Agents; Zoom users with 0patch installed are therefore no longer affected by this issue.

According to our guidelines, we're providing these micropatches to everyone for free until Zoom has fixed the issue or made a decision not to fix it. To minimize the risk of exploitation on systems without 0patch, we're not publishing details on this vulnerability until Zoom has fixed the issue, or made a decision not to fix it, or until such details have become public knowledge in any way.

To obtain the free micropatch for this issue and have it applied on your computer(s), create a free account in 0patch Central, install 0patch Agent and register it to your account. Note that no computer restart is needed for installing the agent or applying/un-applying any 0patch micropatch.

To learn more about 0patch, please visit our Help Center.

Exploit without and with the micropatch

This video demonstrates how an actual attack could look like, and how 0patch blocks the attack. When 0patch is disabled (or absent), user's clicking on the "Start Video" button triggers the vulnerability and leads to a "HACKED" dialog being shown (of course anything else could be executed instead). With 0patch enabled, the vulnerability is removed from the running Zoom.exe process and clicking on the "Start Video" button does not result in execution of malicious code.

Note that in order to prevent revealing too much information, some prior user activity inside Zoom Client user interface is not shown in the video.

Frequently Asked Questions

Q: Am I affected by this vulnerability if I'm using Windows 10 or Windows 8?

A: No, this vulnerability is only exploitable on Windows 7 and earlier Windows versions. It is likely also exploitable on Windows Server 2008 R2 and earlier though we didn't test that; either way, our micropatch will protect you wherever you're using Zoom Client.

Q: Am I affected by this vulnerability if I'm using Windows 7 fully updated with Extended Security Updates?

A: Yes.

Q: Are other Zoom products affected by this vulnerability too?

A:We did not test any other Zoom products, however only those running on Windows could potentially be affected by this vulnerability.

Q: Is your micropatch for this vulnerability completely free?

A: Yes. If you already have 0patch Agent installed and registered, everything will happen automatically. If not, you only need to create a free account in 0patch Central, install 0patch Agent and register it to your account, then all FREE micropatches will be automatically downloaded to your computer and applied as needed. Once Zoom has fixed this issue, this micropatch will no longer be free and will only be available to 0patch PRO license holders.

Q: If I use 0patch to fix this vulnerability, what will happen when Zoom issues an updated version of Zoom Client for Windows?

A: 0patch is designed such that when a vulnerable executable module is replaced by a new version, any micropatches that were made for that vulnerable module automatically stop applying (because the cryptographic hash of the module changes). When Zoom issues an updated Client for Windows and you install it on your computer, our micropatch will become obsolete. In case this updated Zoom Client does not fix this vulnerability, we'll port the micropatch and make it available for free as quickly as possible.

Q: How do I know that the micropatch was actually applied to my Zoom Client?

A: First launch Zoom, then open 0patch Console and view the log. You should be able to find log entries like "Patch ... applied in application Zoom.exe"

Q: I installed 0patch Agent to fix this vulnerability but it is showing a large amount of popups notifying me about missing patches regardless of popup settings in 0patch Console. What can I do to make this stop?

A: We're aware that popups in the FREE plan have become pretty disturbing due to the increased amount of patches, and are fixing that in the next agent version scheduled to be out next week. If you can't wait, feel free to download the current 0patch Agent release candidate and install it on top of your already installed 0patch Agent. When this release candidate is installed, 0patch Console will show that a “New agent is available”. Please ignore that – the server simply tells the agent that the version it is running is not the current official version. The message will stop appearing when the new agent is officially released.

[Below FAQ added on 7/13/2020]

Q: Why did you drop a 0day without giving the vendor the usual 90 days to fix the issue?

A: We have to be perfectly clear here: we did not "drop a 0day". We took extra care not to reveal any technical details. "Dropping a 0day" implies publishing details that allow anyone skilled to reproduce the bug and create an exploit. In over two decades of existence, our company has never "dropped a 0day", moreover we have never published details of unpatched vulnerabilities we had reported to various vendors even if they took extremely long to fix them (while it is standard practice to publish after 90 days). We took the time to write up a detailed report we sent to Zoom, and we took care of our users by providing them with a micropatch. This is what every antivirus/antimalware company does for their users, e.g., by immediately providing signatures for 0days.

Q: Now that Zoom has issued a new version of Client for Windows that fixes this issue, will you publish vulnerability details and proof-of-concept?

A: Our data shows that on the day we issued our micropatches, many 0patch users have been using all supported versions of Zoom Client for Windows instead of the latest one despite of its highly persistent auto-update mechanism. Taking our user base as a statistical sample of the global Zoom user base, this implies a significant amount of Zoom Clients will likely remain vulnerable even though a fixed version is now available. To prevent putting Zoom users who don't also use 0patch at risk, we will not publish any additional details at this time.

Q: Does this vulnerability show that Windows 7 is an insecure operating system?

A: While it may sound so, it really does not. This vulnerability is not a fault of Windows 7 in any way, but just happens to be exploitable there. It is not blocked by some security feature or exploit mitigation on Windows 8 and Windows 10 which isn't there on Windows 7, but by sheer coincidence.

Q: Isn't Windows 7 insecure anyway because Microsoft stopped supporting it?

A: Not really - Microsoft is still providing all critical and important security updates for Windows 7 until January 2023; from security perspective, Windows 7 is therefore effectively just as supported as Windows 10 as long as you're using Microsoft's Extended Security Updates, or, alternatively and less expensively, 0patch.

Community Outreach

We'd like to thank the security researcher who shared the vulnerability with us so we could provide quick protection for our existing users and everyone else affected. We're very pleased to see an increase of such collaboration within security community and call upon all security researchers to help us protect users and share vulnerability information with us, whether or not they have also shared it with the original vendor. We'll do our best to turn your reports into patches as quickly as possible. Thank you all!