Tuesday, October 24, 2023

Micropatches Released For Microsoft Office Security Feature Bypass (CVE-2023-33150) - Plus a Small 0day

 

In July 2023, Microsoft released a patch for CVE-2023-33150, a vulnerability in Microsoft Office that allowed an attacker to create a malicious Word document which would not open in Protected View even though it had the Mark-of-the-Web ("MotW") set.

The first public detail about this vulnerability came from security researcher Eduardo B. Prado, noting that adding a non-breaking space character to the end of a Word document's extension prevents Word from opening the document in Protected View.

Subsequently, Will Dormann published his own research. Will noticed that in the process of opening a file with a non-breaking space in the extension, Word at some point - after normalizing the file path - tried to find the Mark-of-the-Web in a file without the non-breaking space, and failed because no such file existed. Using a flawed logic "no file, no Mark-of-the-Web", Word then decided that it was safe to open the document without Protected View.

To illustrate the issue, suppose a downloaded malicious file with Mark-of-the-Web is named PoC.doc<nbsp>, whereby <nbsp> denotes a non-breaking space. (One can create such file manually by editing the name of the file, placing the cursor at the end of the file name, holding down Alt and typing 255 on the numeric keypad.) Opening such file in Word would lead to Word normalizing the file name at some point (which removes the non-breaking space), and trying to read Mark-of-the-Web from PoC.doc. Since this file does not exist, Word would assume there was no Mark-of-the-Web, even though this mark existed on the malicious file. Believing there was no Mark-of-the-Web, Word would open the file without Protected View.

Microsoft's patch fixed this flawed logic: fully updated Word now still tries to open the file without the trailing non-breaking space, still fails (of course, such file is not there), but then defaults to "Mark-of-the-Web is present" and opens the document in Protected View.

The following video demonstrates the vulnerability on fully updated Office 2013, and shows that 0patch removes it. A PoC.doc file on the desktop has the Mark-of-the-Web and also has a non-breaking space appended to the end of the file name. Opening such file doesn't automatically launch Word, because this exact file extension is not associated with any application, but Windows very friendly offer Microsoft Word as the most likely candidate for opening the file. Word then opens this file without Protected View. With 0patch enabled, opening the same file results in the file being opened in Protected View.

 


 

Since users of Office 2010 and 2013 didn't receive Microsoft's patch for this issue, we created our own micropatches for these versions that fix CVE-2023-33150. All PRO and Enterprise users had these patches automatically applied without even having to relaunch Word.

And now, the 0day....

 


While working on the above vulnerability and its patch, our researchers noticed something strange in the patched version of Word. While Microsoft's patch for CVE-2023-33150 changed the flawed logic of "no file, no Mark-of-the-Web" to a more secure "no file, yes Mark-of-the-Web", the underlying assumption in both cases was that there was no file.

In our tests, while frequently moving, copying and renaming files, fully patched Word sometimes behaved strangely, seemingly randomly not opening the file in Protected View when it should have. It turned out there is another flaw in the other half of the above logic: the half where a file without the non-breaking space at the end happens to exist.

What happens in that case? Well, Word tries to read the Mark-of-the-Web from it and uses it for deciding whether to open the file in Protected View or not.

Suppose we have, like before, a malicious file with the Mark-of-the-Web named PoC.doc<nbsp>: a fully patched Word correctly opens it in Protected View. Suppose we then place another file named PoC.doc next to it without the Mark-of-the-Web and open the first file with Word: Word checks PoC.doc for Mark-of-the-Web and, not finding it, opens the malicious file without Protected View.

Is this a security issue? Let's discuss exploitability. 

Could the attacker who tricked the user into opening a malicious PoC.doc<nbsp> (a file with Mark-of-the-Web) also plant PoC.doc (without Mark-of-the-Web) next to it to make Word open the former without Protected View? If they could, they might as well just plant PoC.doc and have the user open it for the same effect without having to exploit anything.

Alternatively, could the attacker plant a malicious MeetingMinutes.doc<nbsp> (a file with Mark-of-the-Web) next to a previously existing, legitimate MeetingMinutes.doc (without Mark-of-the-Web) on user's computer? Potentially yes: our best attack scenario is for the user to have downloaded a Word document from an intranet web server, which would end up in the Downloads folder without Mark-of-the-Web. The attacker would then trick the user to open MeetingMinutes.doc<nbsp> from their own web server on the Internet, which would result in Word opening this file from the Downloads folder, but would read the Mark-of-the-Web from the legitimate MeetingMinutes.doc, and decide to open the malicious file without Protected View.

This is arguably a pretty far-fetched scenario, and perhaps someone else will think of a better one. With this in mind we reported the issue to Microsoft and expect it to be fixed soon, but did not wait with publication due to very limited exploitability. We did, however, write a micropatch for all supported Word versions (Word 2016, 2019, 2021 and 365) and made it freely available until Microsoft has provided their official fix. Our CVE-2023-33150 patches for Word 2010 and 2013 also fix this vulnerability on these Office versions.

The following video demonstrates the vulnerability and how our patch removes it.



Micropatch Availability

Micropatches were written for the following versions of Microsoft Office with all available updates installed:

  1. Office 2010 (PRO or Enterprise license required)
  2. Office 2013 (PRO or Enterprise license required)
  3. Office 2016 (free until Microsoft provides an official patch)
  4. Office 2019 (free until Microsoft provides an official patch)
  5. Office 2021 (free until Microsoft provides an official patch)
  6. Office 365 (free until Microsoft provides an official patch)
 
 
Micropatches have already been distributed to, and applied on all computers with registered 0patch Agents, 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 Eduardo B. Prado and Will Dormann for sharing their knowledge, which made it possible for us to create a micropatch for this issue.

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

 

Wednesday, October 18, 2023

0patch Security-Adopts Windows 11 v21H2 Home and Pro to Keep it Running Securely

 


 

This October brought the last security updates for Windows 11 version 21H2 Home and Pro versions. Windows 11 require a Trusted Platform Module (TPM) 2.0 to be present on the computer, but for some time, it was possible to install Windows 11 version 21H2 without TPM. Many users have done that and now that this version went out of support, they cannot upgrade to Windows 11 v22H2, and thus cannot receive future security fixes. While many modern CPU versions are supported by Windows 11, computers with unsupported CPU versions are still happily doing their work in large numbers around the World.

To keep these computers secure, we security-adopted Windows 11 v21H2 and will provide critical security patches for it from this month on, for at least one year (and longer if there is sufficient demand).

We have previously security-adopted many other Windows versions, including Windows Server 2012, which has also reached its end of support this month.

If you're running Windows 11 v21H2, all you need to do is install 0patch Agent on the computer and register it to an account with PRO or Enterprise subscription, and you'll start receiving critical security patches as soon as we issue them. In order to have our micropatches applied, Windows 11 v21H2 will have to have October 2023 Windows Updates (the last official updates for this version) installed.

These micropatches will be included in 0patch PRO and Enterprise licenses along with all other micropatches we're issuing - which means that users protecting their Windows 11 v21H2 with 0patch will also receive our micropatches for "0day" vulnerabilities in various products.

We welcome all interested organizations to contact sales@0patch.com for information about pricing, deployment, or setting up a trial.

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

 

Monday, October 9, 2023

Micropatches Released For Two Windows CNG Key Isolation Service Vulnerabilities (CVE-2023-28229, CVE-2023-36906)

 


Last month, security researcher @k0shl of Cyber Kunlun published a proof-of-concept for CVE-2023-28229, an elevation of privilege vulnerability in CNG Key Isolation Service. The same POC also demonstrated exploitation of CVE-2023-36906, an information disclosure vulnerability in the same service discovered by the same researcher.

Microsoft had previously provided fixes for these issues in April and August 2023, respectively. According to CISA, CVE-2023-28229 was found to be exploited in the wild.

 

CVE-2023-28229

This bug is a race condition in the Key Isolation service running in lsass.exe that allows an attacker to use already-freed memory inside a structure. Its root cause is flawed critical section management that protects heap-based data structures from concurrent access but for some reason excludes reference counter initializations and updates. When a user spawns many concurrent threads that call SrvCryptCreatePersistedKey and SrvCryptFreeKey, these threads eventually cause the execution of said functions such that a key data structure is freed in one thread but then still used in another thread by calling the structure destructor method from already deallocated vftable

Microsoft patched this bug in April 2023, and their patch included relocating several critical sections over various pieces of code. Our approach to patching this issue was more minimalistic as we only switched two instructions to place the increasing of the reference counter in function SrvAddKeyToList inside the critical section. It was our assessment that this very instruction was the most critical enabler of exploitability.

During the analysis, we also noticed that this bug doesn't affect Windows 7 and Server 2008 R2 systems as the relevant code in keyiso.dll is completely different there and does not use critical sections in the same way as in newer versions of Windows.

Source code of our patch:



MODULE_PATH "..\AffectedModules\keyiso.dll_10.0.19041.388_Win10-2004_64-bit_u2021-12\keyiso.dll"
PATCH_ID 1509
PATCH_FORMAT_VER 2
VULN_ID 7723
PLATFORM win64
       
patchlet_start
    PATCHLET_ID 1
    PATCHLET_TYPE 2
    PATCHLET_OFFSET 0x2d2f
    N_ORIGINALBYTES 5
    JUMPOVERBYTES 16                       ; remove these two instructions
    PIT ntdll.dll!RtlLeaveCriticalSection
    
    code_start
       
        lock inc dword[rdi+0x8]            ; and re-add them in the reverse order
        call PIT_RtlLeaveCriticalSection
       
    code_end
    
patchlet_end


CVE-2023-36906

This information disclosure issue stems from the way the Key Isolation Service implements SetProviderProperty and GetProviderProperty functions. When calling SetProviderProperty, the attacker can specify a string of some length, but can then request its value using GetProviderProperty specifying a larger length.When this happens, the Key Isolation Service reads the referenced buffer without any additional checks and reveals the content of memory beyond the designated buffer. This allowed the POC to obtain an internal object address, which it can then use to exploit  CVE-2023-28229 in a more reliable way.

Microsoft's patch for this issue added a forced zero-termination of the user-supplied string such that subsequent reading from the buffer could not extract information beyond the bounds of the buffer.

We chose a similar but more minimalistic approach by setting the HEAP_ZERO_MEMORY flag to the RtlAllocateHeap call, causing the allocated space to be initialized with zeroes.

Source code of our patch:
 
 

MODULE_PATH "..\AffectedModules\ncryptprov.dll_10.0.19041.2193_Win10-21H1_64-bit_u2022-12\ncryptprov.dll"
PATCH_ID 1519
PATCH_FORMAT_VER 2
VULN_ID 7795
PLATFORM win64
       
patchlet_start
    PATCHLET_ID 1
    PATCHLET_TYPE 2
    PATCHLET_OFFSET 0x6bf6
    N_ORIGINALBYTES 5
    JUMPOVERBYTES 0
            
    code_start
        add r8, 0x2   ; increase the size of the allocated buffer
        mov edx, 0x8  ; set the HEAP_ZERO_MEMORY flag for the upcoming
                      ; RtlAllocateHeap  call
    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
 
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 @k0shl of Cyber Kunlun 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.