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.