{"id":123988,"date":"2021-06-28T12:44:00","date_gmt":"2021-06-28T19:44:00","guid":{"rendered":"\/blogs\/?p=123988"},"modified":"2024-07-05T06:05:38","modified_gmt":"2024-07-05T13:05:38","slug":"analyzing-cve-2021-1665-remote-code-execution-vulnerability-in-windows-gdi","status":"publish","type":"post","link":"https:\/\/www.mcafee.com\/blogs\/other-blogs\/mcafee-labs\/analyzing-cve-2021-1665-remote-code-execution-vulnerability-in-windows-gdi\/","title":{"rendered":"Analyzing CVE-2021-1665 \u2013 Remote Code Execution Vulnerability in Windows GDI+"},"content":{"rendered":"

Introduction<\/strong><\/h2>\n

Microsoft Windows Graphics Device Interface+, also known as GDI+, allows various applications to use different graphics functionality on video displays as well as printers. Windows applications don\u2019t directly access graphics hardware such as device drivers, but they interact with GDI, which in turn then interacts with device drivers. In this way, there is an abstraction layer to Windows applications and a common set of APIs for everyone to use.<\/p>\n

Because of its complex format, GDI+ has a known history of various vulnerabilities. We at McAfee continuously fuzz various open source and closed source software including windows GDI+. Over the last few years, we have reported various issues to Microsoft in various Windows components including GDI+ and have received CVEs for them.<\/p>\n

In this post, we detail our root cause analysis of one such vulnerability which we found using WinAFL: CVE-2021-1665 – GDI+ Remote Code Execution Vulnerability.\u00a0 This issue was fixed in January 2021 as part of a Microsoft Patch.<\/p>\n

What is WinAFL?<\/strong><\/h2>\n

WinAFL is a Windows port of a popular Linux AFL fuzzer and is maintained by Ivan Fratric of Google Project Zero. WinAFL uses dynamic binary instrumentation using DynamoRIO and it requires a program called as a harness. A harness is nothing but a simple program which calls the APIs we want to fuzz.<\/p>\n

A simple harness for this was already provided with WinAFL, we can enable \u201cImage->GetThumbnailImage<\/strong>\u201d code which was commented by default in the code. Following is the harness code to fuzz GDI+ image and GetThumbnailImage API:<\/p>\n

As you can see, this small piece of code simply creates a new image object from the provided input file and then calls another function to generate a thumbnail image. This makes for an excellent attack vector and can affect various Windows applications if they use thumbnail images. In addition, this requires little user interaction, thus software which uses GDI+ and calls GetThumbnailImage API, is vulnerable.<\/p>\n

Collecting Corpus:<\/strong><\/h2>\n

A good corpus provides a sound foundation for fuzzing. For that we can use Google or GitHub in addition to further test corpus available from various software and public EMF files which were released for other vulnerabilities. We have generated a few test files by making changes to a sample code provided on Microsoft\u2019s site which generates an EMF file with EMFPlusDrawString<\/strong> and other records:<\/p>\n

Ref: https:\/\/docs.microsoft.com\/en-us\/openspecs\/windows_protocols\/ms-emfplus\/07bda2af-7a5d-4c0b-b996-30326a41fa57<\/a><\/p>\n

Minimizing Corpus:<\/strong><\/h2>\n

After we have collected an initial corpus file, we need to minimize it. For this we can use a utility called winafl-cmin.py as follows:<\/p>\n\n\n\n
winafl-cmin.py -D D:\\\\work\\\\winafl\\\\DynamoRIO\\\\bin32 -t 10000 -i inCorpus -o minCorpus -covtype edge -coverage_module gdiplus.dll -target_module gdiplus_hardik.exe -target_method fuzzMe -nargs 2 — gdiplus_hardik.exe @@<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

How does WinAFL work?<\/strong><\/h2>\n

WinAFL uses the concept of in-memory fuzzing. We need to provide a function name to WinAFL. It will save the program state at the start of the function and take one input file from the corpus, mutate it, and feed it to the function.<\/p>\n

It will monitor this for any new code paths or crashes. If it finds a new code path, it will consider the new file as an interesting test case and will add it to the queue for further mutation. If it finds any crashes, it will save the crashing file in crashes folder.<\/p>\n

The following picture shows the fuzzing flow:<\/p>\n

Fuzzing with WinAFL:<\/strong><\/h2>\n

Once we have compiled our harness program, collected, and minimized the corpus, we can run this command to fuzz our program with WinAFL:<\/p>\n\n\n\n
afl-fuzz.exe -i minCorpus -o out -D D:\\work\\winafl\\DynamoRIO\\bin32 -t 20000 —coverage_module gdiplus.dll -fuzz_iterations 5000 -target_module gdiplus_hardik.exe -target_offset 0x16e0 -nargs 2 — gdiplus_hardik.exe @@<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Results:<\/strong><\/h2>\n

We found a few crashes and after triaging unique crashes, and we found a crash in \u201cgdiplus!BuiltLine::GetBaselineOffset<\/strong>\u201d which looks as follows in the call stack below:<\/p>\n

As can be seen in the above image, the program is crashing while trying to read data from a memory address pointed by edx+8. We can see it registers ebx, ecx and edx contains c0c0c0c0 which means that page heap is enabled for the binary. We can also see that c0c0c0c0 is being passed as a parameter to \u201cgdiplus!FullTextImager::RenderLine<\/strong>\u201d function.<\/p>\n

Patch Diffing to See If We Can Find the Root Cause<\/strong><\/h2>\n

To figure out a root cause, we can use patch diffing\u2014namely, we can use IDA BinDiff<\/strong> plugin to identify what changes have been made to patched file. If we are lucky, we can easily find the root cause by just looking at the code that was changed. So, we can generate an IDB file of patched and unpatched versions of gdiplus.dll and then run IDA BinDiff<\/strong> plugin to see the changes.<\/p>\n

We can see that one new function was added in the patched file, and this seems to be a destructor for BuiltLine<\/strong> Object :<\/p>\n

We can also see that there are a few functions where the similarity score is < 1 and one such function is FullTextImager::BuildAllLines<\/strong> as shown below:<\/p>\n

Now, just to confirm if this function is really the one which was patched, we can run our test program and POC in windbg and set a break point on this function. We can see that the breakpoint is hit and the program doesn\u2019t crash anymore:<\/p>\n

Now, as a next step, we need to identify what has been changed in this function to fix this vulnerability. For that we can check flow graph of this function and we see something as follows. Unfortunately, there are too many changes to identify the vulnerability by simply looking at the diff:<\/p>\n

The left side illustrates an unpatched dll while right side shows a patched dll:<\/p>\n