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:
- Windows 10 v21H1
- Windows 10 v20H2
- Windows 10 v2004
- Windows 10 v1909
- Windows 10 v1809
- Windows 10 v1803
- Windows 7 (without ESU, with ESU year 1, 2 and 3)
- Windows Server 2008 R2 (without ESU, with ESU year 1, 2 and 3)
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.
No comments:
Post a Comment