Micropatches Released For Windows Error Reporting Service Elevation of Privilege (CVE-2023-36874)

  

With July 2023 Windows Updates, Microsoft brought a fix for CVE-2023-36874, a local privilege escalation vulnerability in Windows Error Reporting Service that was found both by Google TAG and CrowdStrike to be exploited in the wild in the previous month.

When security researcher Filip Dragovic released a proof of concept for this issue, we could reproduce it and start working on a patch.

The Vulnerability

In short, the Windows Error Reporting Service has a number of functions exposed via its RPC interface, so a local process can ask it to submit a chosen error report via function SubmitReport. This function impersonates the calling process' user and at some point launches wermgr.exe, one of the WER executables. Normally, wermgr.exe would be launched from C:\Windows\System32\, but since the service is impersonating the caller (i.e., the attacker), the CreateProcess function honors any symbolic links the caller may have in place. The attacker can, for instance, create a symbolic link mapping C:\ to an arbitrary location such as C:\Users\public\test , which will be used by the CreateProcess call. Consequently, the WER service would launch C:\Users\public\test\Windows\System32\wermgr.exe, attacker's executable with the same name - and according to the documented behavior of CreateProcess, the executable would be launched with the token of the service (not the impersonation token). In other words: as Local System.

 

The Official Patch

Microsoft's fix for this issue was very simple: they effectively disabled the SubmitReport function by immediately returning error "Not implemented" (0x80004001). This means that it is no longer possible to submit an error report via RPC - and perhaps this was never really needed anyway.

Our Micropatch

Our micropatch is logically identical to Microsoft's, and produces the same behavior.

MODULE_PATH "..\AffectedModules\wercplsupport.dll_10.0.17134.1967_Win10-1803_32-bit_u2021-05\wercplsupport.dll"
PATCH_ID 1488
PATCH_FORMAT_VER 2
VULN_ID 7774
PLATFORM win32
       
patchlet_start
    PATCHLET_ID 1
    PATCHLET_TYPE 2
    PATCHLET_OFFSET 0x82ac
    N_ORIGINALBYTES 5
    JUMPOVERBYTES 0
    PIT wercplsupport.dll!0x82eb        
    code_start
        
        mov eax, 80004001h   ; Error code for "Not Implemented"
        jmp PIT_0x82eb       ; Jump directly to end of function
       
    code_end
patchlet_end

 

Let's see our micropatch in action. With 0patch disabled, the POC manages to create a new user "test" on the computer by launching a fake C:\Users\public\test\Windows\System32\wermgr.exe. With 0patch enabled, the POC fails to do that because wermgr.exe is not being launched from function SubmitReport at all.

Micropatch Availability

Micropatches were written for the following security-adopted versions of Windows with all available Windows Updates installed:

1. Windows 10 v21H1 
2. Windows 10 v20H2
   
3. Windows 10 v2004
4. Windows 10 v1909
5. Windows 10 v1809
6. Windows 10 v1803
   

 

We were unable to reproduce this issue on Windows 7 and Server 2008 R2, and believe it is not exploitable there.

 

Micropatches have 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.

We would like to thank Filip Dragovic for sharing their proof of concept, which made it possible for us to create a micropatch for this issue.

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

 

Micropatches Released For Windows Search Remote Code Execution (CVE-2023-36884)

 

Alongside July 2023 Windows Updates, Microsoft revealed the existence of a 0day that was detected in the wild and assigned it CVE-2023-36884. Without issuing a patch, they titled their original advisory "Office and Windows HTML RCE vulnerability" as exploitation was performed using malicious Word documents, and provided workarounds that could block exploitation.

Very little information was publicly available and exploit samples that were referenced by those who claimed to be in the know seemed convoluted, comprising numerous exploits of old known vulnerabilities. The main source of useful information was security researcher Will Dormann who invested a great deal of effort in publicly dissecting many of these samples and reviewing numerous sources to meticulously separate the wheat from the chaff (see his super long Twitter thread).

In absence of sufficient information on the vulnerability itself, we initially decided to issue a patch that  implemented one of the most effective workarounds recommended by Microsoft - the FEATURE_BLOCK_CROSS_PROTOCOL_FILE_NAVIGATION mitigation for all Office executables. This patch - free for everyone as the issue was still an unpatched 0day - enabled said workaround on all 0patch customers' computers so they didn't have to do that manually (or even know about this 0day).

 

The Official Patch

In August, Microsoft finally provided a patch for CVE-2023-36884, and updated their advisory to reveal that the issue lied in Microsoft Search and that "An attacker can plant a malicious file evading Mark of the Web (MOTW) defenses which can result in code execution on the victim system."

This, combined with Will's analysis of the changed behavior in Windows ZIP file extraction (mostly the latter, really), led us to conclusion that Microsoft's patch for CVE-2023-36884 was focused on randomizing the temporary path where files from a ZIP archive are extracted. Before the August update, a file.txt file opened directly from an archive.zip ZIP file would be extracted to a location like:

C:\Users\username\AppData\Local\Temp\Temp1_archive.zip\file.txt

For a local exploit script running on user's computer this is a predictable location, and if extraction process was terminated by exploit code at the right time, Windows would not put the Mark of the Web (MotW) on the file even if the ZIP file came from the Internet and should not be trusted. The absence of this mark on the extracted file would later result in no security warning when the file was opened. (In the actual exploit, the extracted file would be an executable launched without any warning.)

After the August Windows Update, file extraction was different. The same file would be extracted to this location:

C:\Users\username\AppData\Local\Temp\Temp1710d72f-7438-40d0-be9b-52f7e0651fe9_archive.zip\file.txt

Whereby the added GUID part is random and different each time. This blocks exploitation because the exploit code cannot guess the correct path of the extracted file and can therefore not launch it.

We located Microsoft's patch that introduced this change in zipfldr.dll, inside the CTempFileNameArray::_TryCreatingInPath function.

 

 

Our Micropatch

Our micropatch is logically identical to Microsoft's, and produces the same behavior with extracted files.

PATCH_ID 1487
PATCH_FORMAT_VER 2
VULN_ID 7772
PLATFORM win64
       
patchlet_start
    PATCHLET_ID 1
    PATCHLET_TYPE 2
    PATCHLET_OFFSET 0x18514
    N_ORIGINALBYTES 5
    JUMPOVERBYTES 5
    PIT zipfldr.dll!0x180a0,zipfldr.dll!0x186ad,rpcrt4.dll!UuidCreate,rpcrt4.dll!RpcStringFreeW,rpcrt4.dll!UuidToStringW
    ;zipfldr.dll!0x180a0 __int16 *ConstructString(HINSTANCE, unsigned int, ...)
    ;zipfldr.dll!0x186ad ErrorBlock
    
    code_start

        sub rsp, 0x50             ;Create shadowspace and 2 variables
       
        mov [rsp+0x48], rcx       ;Save rcx
        mov [rsp+0x40], rdx       ;Save rdx
        mov [rsp+0x38], r9        ;Save r9
       
       
        lea rcx, [rsp+0x28]       ;Move var1 to rcx to receive UUID
        call PIT_UuidCreate       ;Call UuidCreate
        cmp eax, 0                ;Check if call succeeded
        jne ERROR                 ;Jump to error block if result != 0
       
        lea rdx, [rsp+0x20]       ;Move var2 to rdx to receive pointer to UUID_STRING
        lea rcx, [rsp+0x28]       ;Move var1 with UUID to rdx
        call PIT_UuidToStringW    ;Call UuidToStringW to convert UUID on var1 to UUID_STRING and move it to var2
        cmp eax, 0                ;Check if the call succeeded
        jne ERROR                 ;Jump to error block if result != 0
       
        mov rcx, [rsp+0x48]       ;Restore rcx
        mov rdx, [rsp+0x40]       ;Restore rdx
        mov r9, [rsp+0x38]        ;Restore r9
        mov r8, [rsp+0x20]        ;Replace r8 with UUID_STRING from var2
        call PIT_0x180a0          ;Call ConstructString that output a full path pointer to rax
        mov qword[rsp+0x38], rax  ;save rax for later
       
        lea rcx, [rsp+0x20]       ;Get the pointer to UUID_STRING from var2 and move it to rcx
        call PIT_RpcStringFreeW   ;Free the UUID_STRING buffer
       
        mov rax, [rsp+0x38]       ;Restore rax we saved earlier
       
        jmp END                   ;Continue normal execution
       
    ERROR:                        ;Error block
        add rsp, 0x50             ;Restore the stack pointer
        jmp PIT_0x186ad           ;Jump to the error block
       
    END:                          ;Normal execution
        add rsp, 0x50             ;Restore stack pointer
       
    code_end
    
patchlet_end

 

Micropatch Availability

Micropatches were written for the following security-adopted versions of Windows with all available Windows Updates installed:

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

 

Micropatches have 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.

We would like to thank Will Dormann for his extensive analysis of exploit samples, related publications, and Microsoft's patch, which made it possible for us to create a micropatch for this issue.

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