Micropatches Released For "QueueJumper" Remote Code Execution in Microsoft Message Queuing (CVE-2023-21554)

 

April 2023 Windows Updates brought a fix for CVE-2023-21554, a remote code execution vulnerability in Microsoft Message Queuing Service. The vulnerability, nicknamed "QueueJumper" was reported to Microsoft by Wayne Low of Fortinet's FortiGuard Lab and Haifei Li with Check Point Research.

The first proof-of-concept became available on April 30, when Omair from Krash Consulting published it on GitHub. Another proof-of-concept by zoemurmure became available on May 18. Both of these made it possible for us to create a micropatch for this issue.

The vulnerability allows a remote unauthenticated attacker to cause memory corruption on a Windows computer running Microsoft Message Queuing Service, which can often be extended to executing arbitrary code on the computer. A detailed technical analysis (in Chinese) was provided by zoemurmure,

While still-supported Windows systems have already received the official vendor fix for this vulnerability, there are Windows systems out there that aren't receiving security fixes from Microsoft anymore. In order to protect these systems, we have created our own micropatches for this vulnerability, which are available through the 0patch service.

Our patch prevents memory corruption in a similar way as Microsoft's. In this rare case, the vulnerable service must be restarted on Windows 10 in order for our patch to get applied because it employs the "arbitrary code execution" exploit mitigation that interferes with our operations. Mind you, Microsoft's patch requires a computer restart, but 0patch micropatches typically get applied without even relaunching vulnerable processes. This is not the case here, so make sure to restart the MSMQ service.

Let's see our micropatch in action. With 0patch disabled, the POC immediately crashes the Microsoft Message Queuing Service. With 0patch enabled, the attack doesn't work anymore because the invalid packet is detected and blocked by our patch.

Micropatch Availability

The micropatch was written for the following security-adopted versions of Windows with all available Windows Updates installed:

1. Windows 10 v21H1
   
2. Windows 10 v2004
3. Windows 10 v1909
4. Windows 10 v1809
5. Windows 7 (without ESU, with ESU year 1, and with ESU year 2)
6. Windows Server 2008 R2 (without ESU, with ESU year 1, and with ESU year 2)

 

This micropatch has already been distributed to, and applied on, all online 0patch Agents in PRO or Enterprise accounts (unless Enterprise group settings prevent that). 

Vulnerabilities like this one get discovered on a regular basis, and attackers know about them all. If you're using Windows that aren't receiving official security updates anymore, 0patch will make sure these vulnerabilities won't be exploited on your computers - and you won't even have to know or care about these things.

If you're new to 0patch, create a free account in 0patch Central, then install and register 0patch Agent from 0patch.com, and email sales@0patch.com for a trial. Everything else will happen automatically. No computer reboot will be needed.

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

We'd like to thank Omair from Krash Consulting and zoemurmure for sharing their POCs, which allowed us to create a micropatch and protect our users against this attack. We also encourage all security researchers to privately share their analyses with us for micropatching.

 

Micropatches for Local Privilege Escalation in Microsoft Installer (CVE-2023-21800)

February 2023 Windows Updates brought a fix for CVE-2023-21800, a vulnerability in Windows Installer that allows a local low-privileged attacker to run their code as Local System. The vulnerability was reported to Microsoft  by Adrian Denkiewicz with Doyensec. Adrian subsequently wrote an article detailing the vulnerability, which allowed us to reproduce it and create a patch for our users.

The vulnerability is in one sense a typical symbolic link issue, the types of which we've been seeing in abundance in the past years, but it is also interesting because it includes a privileged process (msiexec.exe running as Local System) inheriting environment variables from the attacker's parent process. This is something we haven't seen before and it could generally be exploited in different interesting ways.

Adrian decided to exploit it by redefining the PROGRAMDATA environment variable and thereby "redirect the “All Users” profile to the arbitrary location which is writable by the [local attacker]." Installation of a product for all users usually includes creating files in All Users' Start Menu folder - which is normally write-protected against a local non-admin user, but by redirecting this folder to an attacker-controller location allows the attacker to create a symlink there and wait for the installer process to use this symlink. If the symlink points to some system file, this effectively means the installer process (running as Local System) will delete such system file.

Arbitrary file deletion can be turned into arbitrary code execution as Local System, as was first shown by Jonas Lykkegård in 2020 using Windows Error Reporting Service, and subsequently also by Abdelhamid Naceri using Windows Installer.

While still-supported Windows systems have already received an official vendor fix for this vulnerability, there are Windows systems out there that aren't receiving security fixes from Microsoft anymore. In order to protect these systems, we have created our own micropatches for this vulnerability, which are available through the 0patch service.

Our patches add a check to the affected code to see if the path used for deleting a file contains a symlink. If it does, the operation is blocked (the file is not deleted).

Micropatch Availability

The micropatch was written for the following security-adopted versions of Windows with all available Windows Updates installed:

1. Windows 10 v2004
2. Windows 10 v1909
3. Windows 10 v1809
4. Windows 10 v1803
5. Windows 7 (without ESU, with ESU year 1, and with ESU year 2)
6. Windows Server 2008 R2 (without ESU, with ESU year 1, and with ESU year 2)
   

This micropatch has already been distributed to, and applied on, all online 0patch Agents in PRO or Enterprise accounts (unless Enterprise group settings prevent that). 

Vulnerabilities like this one get discovered on a regular basis, and attackers know about them all. If you're using Windows that aren't receiving official security updates anymore, 0patch will make sure these vulnerabilities won't be exploited on your computers - and you won't even have to know or care about these things.

If you're new to 0patch, create a free account in 0patch Central, then install and register 0patch Agent from 0patch.com, and email sales@0patch.com for a trial. Everything else will happen automatically. No computer reboot will be needed.

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

We'd like to thank Adrian Denkiewicz with Doyensec for sharing their POC, which allowed us to create a micropatch and protect our users against this attack. We also encourage all security researchers to privately share their analyses with us for micropatching.

Micropatch for Microsoft Outlook Notification File NTLM Hash Theft (CVE-2023-23397, CVE-2023-29324)

 

March 2023 Windows Updates fixed CVE-2023-23397, a vulnerability in Microsoft Outlook that was found to be exploited in the wild since at least January this year. Microsoft revealed very little information but security researcher Dominic Chell of MDSec was quick to figure out what it was about and had a working exploit within hours of Microsoft's update release. Dominic's analysis was released soon thereafter, and POCs started cropping up all over the place.

The vulnerability allows an attacker to send the victim an email such that even without the victim reading this email, Outlook will try to play a notification sound from a file specified in attacker's email (weird, huh?). While the more playful among us would immediately think of  rickrolling our friends, serious attackers could use this "feature" to extract victim's NTLM hash from their computer. Specifying a sound file on a network location such as \\attacker.com\hash_collector.mp3 would make user's Outlook send a network request to attacker's server, which would then request authentication, and user's computer would respond with user's NTLM hash. For some reason, this also works with hosts on the Internet, where NTLM hashes are usually not being sent.

The official patch from Microsoft surprisingly didn't just axe this weird feature, but rather limited the location of the notification sound that your email sender wants you to hear to Local Intranet and Trusted Zones - if the supplied path is elsewhere, no sound will be played. This means that an attacker can still make your Outlook send your NTLM hash to any computer in the local network without you being able to prevent that - which is great news for attackers sitting in your network trying to elevate their privileges and become you.

As a workaround in lieu of patching, Microsoft suggested users to "block TCP 445/SMB outbound from your network by using a perimeter firewall, a local firewall, and via your VPN settings. This will prevent the sending of NTLM authentication messages to remote file shares." This mitigation was later found to be incomplete, as Windows automatically try to use WebDAV for accessing remote shares when an SMB connection attempt fails.

While still-supported Microsoft Office versions have already received an official vendor fix for this vulnerability, Office 2010 - which we have security-adopted - is also vulnerable. In order to protect our Office 2010 users, we have created our own micropatch for this vulnerability.

Our patch is different to Microsoft's, as we believe theirs unnecessary leaves an important part of attack surface open. We therefore decided to simply enforce the default notification sound and completely ignore what your sender wanted you to hear. Granted, if your eager admin has set up some custom sound file for Outlook notifications, our patch will play the default notification sound instead of that as well.

Update 5/10/2023: Our worries about Microsoft's patch turned out to be justified as Akamai researcher Ben Barnea found a simple way to bypass it. Adding a single back slash to the attacker-supplied path did the trick. Our patch blocks this bypass (assigned CVE-2023-29324) by design, so neither we nor our users have to do anything to remain protected against both the old and the new issue. We remain puzzled at Microsoft's insistence to keep this weird and attacker-friendly feature alive.

This is the source code of our patch. It merely overrides the provided sound file path with "reminder.wav", which is the default value for Outlook reminders.

MODULE_PATH "..\Affected_Modules\outlook.exe_14.0.7268.5000_Office-2010_64bit\outlook.exe"
PATCH_ID 1322
PATCH_FORMAT_VER 2
VULN_ID 7684
PLATFORM win64

patchlet_start
    PATCHLET_ID 1
    PATCHLET_TYPE 2
    PATCHLET_OFFSET 0x51d260
    N_ORIGINALBYTES 5
    JUMPOVERBYTES 0

    code_start
       
        call VAR
        dw __utf16__('reminder.wav'), 0 ; The default notification for Outlook 2010
    VAR:
    
        pop rsi
       
    code_end
patchlet_end

 

Micropatch Availability

The micropatch was written for the following security-adopted versions of Office with all available updates installed:

1. Microsoft Office 2010
   

This micropatch has already been distributed to, and applied on, all online 0patch Agents in PRO or Enterprise accounts (unless Enterprise group settings prevented that). 

Vulnerabilities like this one get discovered on a regular basis, and attackers know about them. If you're using Office 2010, or soon-to-be-expired Office 2013 that goes out of support in April this year, 0patch will make sure such vulnerabilities won't be exploited on your computers - and you won't even have to know or care about updating.

If you're new to 0patch, create a free account in 0patch Central, then install and register 0patch Agent from 0patch.com, and email sales@0patch.com for a trial. Everything else will happen automatically. No computer reboot will be needed.

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

We'd like to thank Dominic Chell for sharing their analysis, which allowed us to create a micropatch and protect our users against this attack. We also encourage all security researchers to privately share their analyses with us for micropatching.

Update 5/10/2023: We'd also like to thank Ben Barnea for sharing the analysis of their patch bypass.

 

Micropatches for Microsoft Word Remote Code Execution (CVE-2023-21716)

 

 

February 2023 Windows Updates brought a fix for  CVE-2023-21716, a remote code execution vulnerability in Microsoft Word. The vulnerability was discovered and reported by security researcher Joshua J. Drake (Twitter, Mastodon), and subsequently published with a simple proof-of-concept.

The flaw is in Word's processing of an RTF file with an excessive number of font records, whereby a numeric operation with sign extension results in the code writing to an address outside the intended memory block. With sufficient heap grooming, arbitrary code execution could be possible upon user merely opening a malicious Word document, previewing it in Explorer's Preview Pane, or viewing a malicious email in Outlook. This vulnerability apparently goes back to Office 97.

Microsoft's patch for this issue is not subtle at all: when a sufficiently large number of font records (specifically, more than 32760) is detected in an RTF document, Word just terminates itself. This approach is not new and has reportedly been used before, but may have negative side effects such as lost data (Word crashing while editing an unsaved document) or being unable to use Outlook because it displays the malicious email every time you open it - and crashes.

While still-supported Microsoft Office versions have already received an official vendor fix for this vulnerability, Office 2010 - which we have security-adopted - is also vulnerable. In order to protect our Office 2010 users, we have created our own micropatches for this vulnerability. They are already available through the 0patch service.

 

Our patches are logically equivalent to Microsoft's patches for this issue.

MODULE_PATH "..\Affected_Modules\wwlib.dll_14.0.7268.5000_Office-2010_64bit\wwlib.dll"
PATCH_ID 1315
PATCH_FORMAT_VER 2
VULN_ID 7683
PLATFORM win64

patchlet_start
    PATCHLET_ID 1
    PATCHLET_TYPE 2
    PATCHLET_OFFSET 0x2f3cd6
    N_ORIGINALBYTES 5
    JUMPOVERBYTES 0
    PIT kernel32.dll!TerminateProcess,kernel32.dll!GetCurrentProcess
    
    code_start
           
        lea r9, [rsi+0Ah]          ; add 0Ah to the current font table index
        lea eax, [r9+8000h]        ; add 8000h
        cmp eax, 0FFFFh            ; check if sign extension would happen
        jbe CONTINUE               ; if not, continue normal execution
       
        call PIT_GetCurrentProcess ; retrieve a pseudo handle for the current process,
                                   ; currently -1, For compatibility with future operating
                                   ; systems, it is best to call GetCurrentProcess
                                   ; instead of hard-coding this constant value
        call PIT_ExploitBlocked    ; Exploit Blocked popup
        mov rcx, rax               ; handle (-1)
        mov rdx, 0xbadbaffa        ; exit code
        call PIT_TerminateProcess  ; terminates the specified process and all of its threads
       
    CONTINUE:
    
    code_end
patchlet_end

 

Micropatch Availability

The micropatch was written for the following security-adopted versions of Office with all available updates installed:

1. Microsoft Office 2010
   

This micropatch has already been distributed to, and applied on, all online 0patch Agents in PRO or Enterprise accounts (unless Enterprise group settings prevented that). 

Vulnerabilities like this one get discovered on a regular basis, and attackers know about them. If you're using Office 2010, or soon-to-be-expired Office 2013 that goes out of support in April this year, 0patch will make sure such vulnerabilities won't be exploited on your computers - and you won't even have to know or care about updating.

If you're new to 0patch, create a free account in 0patch Central, then install and register 0patch Agent from 0patch.com, and email sales@0patch.com for a trial. Everything else will happen automatically. No computer reboot will be needed.

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

We'd like to thank Joshua J. Drake (Twitter, Mastodon) for sharing their POC, which allowed us to create a micropatch and protect our users against this attack. We also encourage all security researchers to privately share their analyses with us for micropatching.

 

Goodbye, Pesky Edge Notification, You're Not Needed Anymore!

 

We security-adopted Microsoft Edge version 109 in January to allow 0patch users staying on Windows 7 or Windows Server 2008 R2 to browse the web securely. These Windows versions stopped getting security fixes for Edge, and Edge won't update beyond version 109 on them. Any PRO or Enterprise 0patch subscription now delivers critical security patches both for the operating system and the Edge browser, which makes for a lot of happy 0patch users.

There's one thing, though, that kept disturbing the peace: the pesky notification Edge was showing, reminding users that they should upgrade to Windows 10 or later, which they had clearly decided not to do. It makes sense for this warning to be displayed on a computer without 0patch, but with 0patch - nah, we needed to get it removed.

 

The persistent Edge notification, consuming screen real estate and narrowing user's world view

Users asked, and we delivered. Our hot-patching technology allows us not only to fix security flaws but also to change functional behavior of Windows applications. Now that Edge has stabilized on version 109.0.1518.78, we created two patches that address said notification. Let's look at their effect.

 

FREE patch, delivered to all 0patch users regardless of their license or lack thereof

If you're using 0patch FREE, you're getting our 0day patches (as long as the vulnerability remains a 0day) but not all security patches. Users sometimes misunderstand what they're getting with 0patch FREE, and sometimes subscriptions expire without users noticing it, so we decided to use the Edge notification to warn them about it. With 0patch FREE, Edge will now show this message:

 

0patch FREE alerts you that you're not getting all security patches

 

PRO patch, delivered to all 0patch users with PRO or Enterprise license

PRO and Enterprise 0patch users are getting all our security patches, so there's no need to take away their screen real estate or attention; Edge thus shows no notification on their computers:

No notification for PRO and Enterprise 0patch users

 

In addition, Edge's About page shows that Edge is secured by 0patch:

It would take more code to remove the duplicate message and we prefer less code.

Alternatively, one could also remove the Edge notification via registry, and our patches won't interfere: they'll still be getting applied, but even with 0patch FREE no notification will be shown.

If you're using 0patch and Edge on Windows 7 or Server 2008 R2, make sure to have Edge updated to the last available version (109.0.1518.78 *) and launch Edge to verify that it behaves as described above. If anything is unclear, contact our support by emailing support@0patch.com.

* Update 3/30/2023: Contrary to their announcement, Microsoft made a further Edge v109 update available to Windows 7 and Server 2008 R2 computers in March 2023, namely version 109.0.1518.95. We had to port our patches and recommend updating Edge to this version.

 

Micropatches For Windows CryptoAPI Spoofing (CVE-2022-34689)

 

August 2022 Windows Updates* brought a fix for CVE-2022-34689, a vulnerability in Windows CryptoAPI that allows an attacker to trick some Windows applications - depending on their use of CryptoAPI certificate caching - into accepting a fraudulent certificate. The vulnerability was reported to Microsoft  by UK NCSC and the NSA, but subsequently Tomer Peled and Yoni Rozenshein of Akamai reverse engineered Microsoft's patch and provided a detailed analysis with a proof-of-concept.

(* While Microsoft published this information in October, they had silently provided the patch two months earlier.)

The vulnerability is actually a cryptographic flaw, whereby broken MD5 hashing algorithm is used for identifying cached certificates. This allows the attacker to trick a Windows application into misidentifying a fraudulent certificate for a valid, cached one, because they both have the same MD5 hash.

It is hard to say which applications are vulnerable; any Windows application using CryptoAPI with certificate caching is a potential candidate, but exploitability may depend on how the application is being used. For instance, Akamai researchers have identified old Chrome versions to be vulnerable, allowing a malicious web site with a fake certificate to impersonate a valid web site.

While still-supported Windows systems have already received the official vendor fix for this vulnerability, there are Windows systems out there that aren't receiving security fixes from Microsoft anymore. In order to protect these systems, we have created our own micropatches for this vulnerability, which are available through the 0patch service.

Our patches are logically equivalent to Microsoft's patches for this issue.

MODULE_PATH ".\crypt32.dll"
PATCH_ID 1000006
PATCH_FORMAT_VER 2
VULN_ID 1000007
PLATFORM win64

patchlet_start
    PATCHLET_ID 1
    PATCHLET_TYPE 2
    PATCHLET_OFFSET 0x159f9
    N_ORIGINALBYTES 5
    JUMPOVERBYTES 0
    PIT msvcrt!memcmp,crypt32!0x18c14,crypt32!0x15a01,crypt32!0x15a26
    
    ; 0x18c14 -> CCertObject::Release
    ; 0x15a01 -> FindEndObjectByHash block
    ; 0x15a26 -> Nevem še
    
    code_start
    
        mov rsi, rax        ; rax contains the returned certificate structure
                            ; when searching the cache
        test rax, rax       ; check if a certificate was found in the cache
        jz LABEL            ; jump to LABEL if no certificate was found
       
        mov rcx, [rax+58h]  ; get cached cerfiticate context
        mov rdx, [rsp+50h]  ; struct _CERT_CONTEXT *, current certificate
        mov eax, [rcx+10h]  ; get cached certificate length
        cmp eax, [rdx+10h]  ; compare length from cached and current certificate
        jnz LABEL2          ; jump to LABEL2 if lengths are not equal
       
        mov rdx, [rdx+8]    ; first buffer, current certificate context
        mov r8d, eax        ; number of characters to compare
        mov rcx, [rcx+8]    ; second buffer, cached certificate context
        call PIT_memcmp     ; compares characters in two buffers
        test eax, eax       ; memcmp returns 0 if equal
        jz LABEL            ; jump to LABEL if both contextes were equal
       
    LABEL2:
        mov rcx, rsi        ; contains the returned certificate structure
                            ; when searching the cache
        call PIT_0x18c14    ; call CCertObject::Release
                            ; release decrements the number of references to the certificate
                            ; if references are 0 then ~CCertObject and PkiFree are called.
        xor rsi, rsi        ; set rsi to 0
        mov [rsp+58h], rsi  ; set pointer to cached certificate to 0
       
    
    LABEL:
        test rsi, rsi       ; is the context of the cached certificate equal?
        jnz PIT_0x15a26     ; yes, they are equal, trust the certificate
        jmp PIT_0x15a01     ; no, context not equal, don't trust the certificate

    code_end
patchlet_end

 

Micropatch Availability

The micropatch was written for the following security-adopted versions of Windows with all available Windows Updates installed:

1. Windows 10 v2004
2. Windows 10 v1909
3. Windows 10 v1809
4. Windows 10 v1803
5. Windows 7 (without ESU, with ESU year 1, and with ESU year 2)
6. Windows Server 2008 R2 (without ESU, with ESU year 1, and with ESU year 2)
   

This micropatch has already been distributed to, and applied on, all online 0patch Agents in PRO or Enterprise accounts (unless Enterprise group settings prevent that). 

Vulnerabilities like this one get discovered on a regular basis, and attackers know about them all. If you're using Windows that aren't receiving official security updates anymore, 0patch will make sure these vulnerabilities won't be exploited on your computers - and you won't even have to know or care about these things.

If you're new to 0patch, create a free account in 0patch Central, then install and register 0patch Agent from 0patch.com, and email sales@0patch.com for a trial. Everything else will happen automatically. No computer reboot will be needed.

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

We'd like to thank Tomer Peled and Yoni Rozenshein of Akamai for sharing their POC, which allowed us to create a micropatch and protect our users against this attack. We also encourage all security researchers to privately share their analyses with us for micropatching.

 

Micropatches for Windows COM+ Event System Service Elevation of Privilege Vulnerability (CVE-2022-41033)

 

October 2022 Windows Updates brought a fix for CVE-2022-41033, a local privilege escalation vulnerability in Windows COM+ Event System Service. The vulnerability was reported to Microsoft by an anonymous source, but subsequently James Forshaw of Google Project Zero published their analysis, which included proof of concept code.

This "type confusion" vulnerability allows a local low-privileged attacker to provide a memory address of their choosing to vulnerable code. The POC demonstrates reading from such address (and crashes the Event System Service process as a result) but this issue was reported as exploited in the wild, so attackers must have successfully turned it into a privilege escalation.

While still-supported Windows systems have already received the official vendor fix for this vulnerability (assuming admins have applied the October 2022 or later Windows Update), there are Windows systems out there that aren't receiving security fixes from Microsoft anymore. In order to protect these systems, we have created our own micropatches for this vulnerability, which are available through the 0patch service.

Our patches are logically equivalent to Microsoft's patches for this issue.

MODULE_PATH "..\AffectedModules\es.dll_10.0.19041.572_Win10_2004_64bit_u202212\es.dll"
PATCH_ID 1310
PATCH_FORMAT_VER 2
VULN_ID 7646
PLATFORM win64

patchlet_start
PATCHLET_ID 1
PATCHLET_TYPE 2
PATCHLET_OFFSET 0xe669
JUMPOVERBYTES 0
N_ORIGINALBYTES 5
PIT es.dll!0x24eaa

code_start
       
    cmp word[r8], 0x101f    ;check if Names.vt == (VT_VECTOR | VT_LPWSTR)
    jne ERROR               ;if not, report error
    cmp word[r9], 0x100c    ;check if Values.vt == (VT_VECTOR | VT_VARIANT)
    jne ERROR               ;if not, report error
    mov eax, dword[r9+0x8]  ;move Names->calpwstr.cElems to eax for cmp
    cmp dword[r8+0x8], eax  ;compare Names->calpwstr.cElems == Values->capropvar.cElems
    jne ERROR               ;if not equal, report error
    jmp SUCCESS             ;if all checks pass, continue with normal execution
       
ERROR:
    jmp PIT_0x24eaa         ;in case of error jump to the block that returns 0x80070057
           
SUCCESS:
           
    code_end
patchlet_end

 

Let's see our micropatch in action. With 0patch disabled, the POC immediately crashes the Event System Service. With 0patch enabled, the attack doesn't work anymore because the invalid type is detected and blocked by our patch.

Micropatch Availability

The micropatch was written for the following security-adopted versions of Windows with all available Windows Updates installed:

1. Windows 10 v2004
2. Windows 10 v1909
3. Windows 10 v1809
4. Windows 10 v1803

 

Note that Windows 7 and Server 2008 R2 are not affected by this vulnerability, and Windows 10 v21H1 was still receiving official Windows Updates in October 2022, and therefore doesn't need out patch.

This micropatch has already been distributed to, and applied on, all online 0patch Agents in PRO or Enterprise accounts (unless Enterprise group settings prevent that). 

Vulnerabilities like this one get discovered on a regular basis, and attackers know about them all. If you're using Windows that aren't receiving official security updates anymore, 0patch will make sure these vulnerabilities won't be exploited on your computers - and you won't even have to know or care about these things.

If you're new to 0patch, create a free account in 0patch Central, then install and register 0patch Agent from 0patch.com, and email sales@0patch.com for a trial. Everything else will happen automatically. No computer reboot will be needed.

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

We'd like to thank James Forshaw of Google Project Zero for sharing their POC, which allowed us to create a micropatch and protect our users against this attack. We also encourage all security researchers to privately share their analyses with us for micropatching.

 

0patch Agent 22.11.11.10550 Released

 

Today we released a new version of 0patch Agent that fixes some issues reported by users or detected internally by our team. We always recommend keeping 0patch Agent updated to the latest version, as we only support the last couple of versions; not updating for a long time could lead to new patches no longer being downloaded and agent not being able to sync to the server properly. 

Enterprise users can update their agents centrally via 0patch Central; if their policies mandate automatic updating for individual groups, agents in such groups will get updated automatically.

Non-enterprise users will have to update 0patch Agents manually by logging in to computers with 0patch Agent and pressing "GET LATEST VERSION" in 0patch Console.

We recommend automatically updating 0patch Agent: to enable automatic updates, see this article.

The latest 0patch Agent is always downloadable from https://dist.0patch.com/download/latestagent.

Release notes are available here.

An enormous THANK YOU to all users who have been reporting technical issues to our support team, some of you investing a lot of time in investigating problems and searching for solutions or workarounds. You helped us make our product better for everyone!

 

WARNING: We have users reporting that some anti-virus products seem to detect the new agent as malicious and block its installation or execution. Specifically, Avast detects 0patchServicex64.exe as malicious (preventing proper functioning of the agent). We have reported false positives to antivirus vendors. If you're affected, we recommend marking any antivirus detection of 0patch-related files occurring soon after agent update as a false positive, restoring quarantined files and making an exception for these files.

 

 

 

Micropatching the "LocalPotato" NTLM Elevation of Privilege (CVE-2023-21746)

 

January 2023 Windows Updates brought a fix for CVE-2023-21746, a local privilege escalation vulnerability in Windows, called "LocalPotato" by its discoverers  Andrea Pierini and Antonio Cocomazzi. Its name is in reference to many other "potato" vulnerabilities that have been discovered in Windows since 2014 when James Forshaw of Google Project Zero published their analysis of Local WebDAV NTLM Reflection.

The potato vulnerability at hand, "LocalPotato", was reported to Microsoft by Andrea and Antonio and will, now that the official fix has been available for a month, soon be published at https://www.localpotato.com/.

While still-supported Windows systems have already received the official vendor fix for this vulnerability (assuming admins have applied the January 2023 Windows Update), there are many Windows systems out there that aren't receiving security fixes from Microsoft anymore. In order to protect these systems, we have created our own micropatches for this vulnerability, which are available through the 0patch service.

Our patches are logically equivalent to Microsoft's patches for this issue.

Let's see our micropatch in action. With 0patch disabled, the POC launched by a low-privileged user creates a file localpotato.exe in C:\Windows folder. (Of course this means that any other file could have been created, including a DLL that some high-privileged process would gladly load and run code from.) With 0patch enabled, the attack is blocked and no file is created.

Micropatch Availability

The micropatch was written for the following Versions of Windows with all available Windows Updates installed: 

1. Windows 10 v21H1
2. Windows 10 v2004
3. Windows 10 v1909
4. Windows 10 v1809
5. Windows 10 v1803
6. Windows 7 (no ESU, ESU years 1 and 2)
7. Windows Server 2008 R2 (no ESU, ESU years 1 and 2)

 

Note that Windows 7 and Server 2008 R2 with ESU year 3 have received Microsoft's patch with January Updates.

This micropatch has already been distributed to, and applied on, all online 0patch Agents in PRO or Enterprise accounts (unless Enterprise group settings prevent that). 

Vulnerabilities like this one get discovered on a regular basis, and attackers know about them all. If you're using Windows that aren't receiving official security updates anymore, 0patch will make sure these vulnerabilities won't be exploited on your computers - and you won't even have to know or care about these things.

If you're new to 0patch, create a free account in 0patch Central, then install and register 0patch Agent from 0patch.com, and email sales@0patch.com for a trial. Everything else will happen automatically. No computer reboot will be needed.

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

We'd like to thank Andrea Pierini and Antonio Cocomazzi for sharing their POC with us which allowed us to create a micropatch before details were released to the public. We also encourage other security researchers to privately share their analyses with us for micropatching.

 

Micropatching Arbitrary File Delete Vulnerability in Windows Backup Service (CVE-2023-21752)

 

January 2023 Windows Updates brought a fix for a local privilege escalation vulnerability in Windows Backup Service, discovered and reported by Filip Dragovic. The vulnerability allows a non-admin user on the machine to execute arbitrary code as Local System and thereby take over the computer.

 

The Backup Service

The intended use of the Backup Service is through local user interface of the legacy "Backup and Restore (Windows 7)" component, still existing on all Windows 10 and Windows 11 computers. A privileged user launches Backup and Restore, selects the backup destination and what they want to backup, and starts or schedules a backup. The destination can either be a local drive or a network path, and in the latter case, network credentials have to be supplied as well. The Backup Service uses these credentials for accessing the network share.

The Vulnerability

The vulnerability lies in the way Windows Backup Service tries to determine whether the user whose credentials were supplied has write access on the chosen destination or not. Specifically, the service attempts to create a temporary, randomly-named file on the destination path using these credentials; if this fails, the path is considered non-writable and the backup procedure can't continue, but if temporary file creation succeeds, the file is immediately deleted and the backup procedure can continue as the path is confirmed to be writable.

Now, the process of creating and deleting this temporary file is vulnerable to a TOCTOU symbolic link attack. As Filip has demonstrated, a local low-privileged attacker can trigger the backup process with some path under their control, catch the temporary file which the Backup Service creates (and hold it locked), replace it with a symbolic link to some system file they could not otherwise delete, and let the Backup Service continue with deleting said system file. This results in the service deleting a chosen file, which can be exploited for arbitrary code execution as Local System as was first shown by Jonas Lykkegård in 2020 using Windows Error Reporting Service, and subsequently also by Abdelhamid Naceri using Windows Installer. Filip's POC makes use of the latter.

But, one could reasonably ask, why does the Backup Service use its own Local System identity instead of user-supplied credentials for creating and deleting the temporary file? Well, it turns out that user-supplied credentials are indeed used for network paths pointing to other computers - but when a share on the same computer is used (such as \\127.0.0.1\C$, the computer's administrative share), the service keeps using its own identity, i.e. Local System.

Microsoft's Patch

Microsoft's patch for this vulnerability introduced a completely redesigned test for path writability, whereby a temporary file is created using the FILE_FLAG_DELETE_ON_CLOSE flag. This flag makes sure that the file, if created, would get automatically deleted when closed - making this entire test an atomic operation from the perspective of TOCTOU shenanigans.

Our Micropatch

Our micropatch is logically identical to Microsoft's, but to minimize its complexity and code size we opted for a simpler naming of the temporary file: we start with creating a file 0patchTMP_A.tmp, then failing that continue with 0patchTMP_B.tmp, and so on until 0patchTMP_Z.tmp. If any of these files can be created, the path is considered writable, otherwise it is considered unwritable.

This is to accommodate multiple backup processes using the same path at the same time, which is unlikely but not impossible. One might think that an attacker could create files 0patchTMP_A.tmp through 0patchTMP_Z.tmp on the backup path to trick our patch into thinking the path was unwritable, but then again, if the attacker has write access to your backup location, no patch is going to save you.

Let's see our micropatch in action. With 0patch disabled, Filip's POC can delete a file on the root of C: drive by exploiting the described vulnerability. With 0patch enabled and our micropatch in place, the vulnerability is no longer there and the same file does not get deleted.

Micropatch Availability

The micropatch was written for the following Versions of Windows with all available Windows Updates installed: 

1. Windows 10 v21H1
2. Windows 10 v2004
3. Windows 10 v1909
4. Windows 10 v1809
5. Windows 10 v1803
6. Windows 7 (no ESU, ESU years 1 and 2)
7. Windows Server 2008 R2 (no ESU, ESU years 1 and 2)

 

Note that Windows 7 and Server 2008 R2 with ESU year 3 have received Microsoft's patch with January Updates.

This micropatch has already been distributed to, and applied on, all online 0patch Agents in PRO or Enterprise accounts (unless Enterprise group settings prevent that). 

If you're new to 0patch, create a free account in 0patch Central, then install and register 0patch Agent from 0patch.com, and email sales@0patch.com for a trial. Everything else will happen automatically. No computer reboot will be needed.

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

We'd like to thank  Filip Dragovic for sharing details about this vulnerability, which allowed us to create a micropatch and protect our users. We also encourage security researchers to privately share their analyses with us for micropatching.

 

0patch Security-Adopts Microsoft Edge on Windows 7, Server 2008 and Server 2012

 

As we announced two more years of critical security patches for Windows 7 and Server 2008 R2, users started asking how they could keep browsing web sites securely given that all major browsers (Chrome, Firefox*, Edge, Brave, Vivaldi) would lose support on these Windows versions in January 2023. In addition, even on Windows Server 2012, Edge will stop getting official security updates from Microsoft in January, although the server itself is still supported until October this year - which came as quite a surprise to many organizations. **

(* Anonymous reader correctly noted that Mozilla has not yet made a formal statement on ending Firefox support on these Windows versions.)

(** Sometime between January 17 and 19, Microsoft updated their documentation with "Microsoft Edge version 109 will receive critical security fixes and fixes for known exploit bugs until October 10, 2023 [on Windows Server 2012]")

Microsoft Edge version 109, deployed in the week of January 12, will therefore remain the last Edge version on all these Windows systems, and it will not get any security patches anymore.

... security patches from Microsoft, that is.

We at 0patch have decided to security-adopt Edge version 109 and provide critical security patches for it so you can keep using Windows 7, Server 2008 R2 with Edge in a secure way. With 0patch, you'll also be able to keep using Windows Server 2012 (non-R2 or R2) with Edge securely until their end of official support by Microsoft in October 2023... which is when we'll also security-adopt this server version and you'll be able to keep using it securely even longer.

To have Edge patched by 0patch, do the following:

1. Let Edge update to version 109 - which should happen automatically as you restart the browser. Make sure your Edge update settings allow updates and to be sure, manually check that you have version 109. (The version will likely be shown as 109.x.xxxx.xx so make sure you see 109 at the beginning.)
   
2. Keep the "Download and install updates automatically" setting enabled in case Microsoft decides to provide further updates for some reason. If they do, we will migrate our support to the then-latest version of Edge on these Windows versions without you having to do anything else.
3. Finally, unless you already have it, install 0patch Agent on all your affected Windows computers and register it to your 0patch account holding a suitable amount of licenses. 

Edge security patches will be part of Pro and Enterprise license, so if you're already using 0patch on your computers, Edge patches will be automatically included for no extra cost.

We'll be happy to set you up with a trial so you can see how 0patch works and how it co-exists with other components in your environment. Just email sales@0patch.com and you'll be quickly on your way.

P.S.: We'll also try to remove that "To get future Microsoft Edge updates, you'll need Windows 10 or later." notification that keeps getting displayed in Edge when you launch it. [Update 3/8/2023: Done]

Frequently Asked Questions

Q: How long do you plan to provide critical security patches for Edge?

A: Initially for two more years - until January 2025 -, to match our support for Windows 7 and Server 2008 R2. Depending on the demand, we'll consider a further extension.

Q: Will you patch all vulnerabilities in Edge version 109 that Microsoft patches in the current Edge version?

A:No, just the critical ones that we have sufficient details on. Fortunately, these are the exact vulnerabilities attackers are interested in exploiting.

Q: Will you also keep patching Internet Explorer on all these Windows versions?

A: Yes. Internet Explorer components are a part of Windows operating system and even if Internet Explorer is not being used, its components are often used by other products, for instance Microsoft Office. We will keep considering Internet Explorer as part of Windows and provide critical security patches for all its components.

Q: We have more questions about 0patch

A: Our Help Center has a lot of answers but if you can't find yours there, feel free to contact us at sales@0patch.com.