Introduction
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’t 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.
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.
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. This issue was fixed in January 2021 as part of a Microsoft Patch.
What is WinAFL?
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.
A simple harness for this was already provided with WinAFL, we can enable “Image->GetThumbnailImage” code which was commented by default in the code. Following is the harness code to fuzz GDI+ image and GetThumbnailImage API:
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.
Collecting Corpus:
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’s site which generates an EMF file with EMFPlusDrawString and other records:
Ref: https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-emfplus/07bda2af-7a5d-4c0b-b996-30326a41fa57
Minimizing Corpus:
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:
| 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 @@ |
How does WinAFL work?
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.
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.
The following picture shows the fuzzing flow:
Fuzzing with WinAFL:
Once we have compiled our harness program, collected, and minimized the corpus, we can run this command to fuzz our program with WinAFL:
| afl-fuzz.exe -i minCorpus -o out -D D:workwinaflDynamoRIObin32 -t 20000 —coverage_module gdiplus.dll -fuzz_iterations 5000 -target_module gdiplus_hardik.exe -target_offset 0x16e0 -nargs 2 — gdiplus_hardik.exe @@ |
Results:
We found a few crashes and after triaging unique crashes, and we found a crash in “gdiplus!BuiltLine::GetBaselineOffset” which looks as follows in the call stack below:
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 “gdiplus!FullTextImager::RenderLine” function.
Patch Diffing to See If We Can Find the Root Cause
To figure out a root cause, we can use patch diffing—namely, we can use IDA BinDiff 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 plugin to see the changes.
We can see that one new function was added in the patched file, and this seems to be a destructor for BuiltLine Object :
We can also see that there are a few functions where the similarity score is < 1 and one such function is FullTextImager::BuildAllLines as shown below:
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’t crash anymore:
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:
The left side illustrates an unpatched dll while right side shows a patched dll:
- Green indicates that the patched and unpatched blocks are same.
- Yellow blocks indicate there has been some changes between unpatched and patched dlls.
- Red blocks call out differences in the dlls.
If we zoom in on the yellow blocks we can see following:
We can note several changes. Few blocks are removed in the patched DLL, so patch diffing will alone will not be sufficient to identify the root cause of this issue. However, this presents valuable hints about where to look and what to look for when using other methods for debugging such as windbg. A few observations we can spot from the bindiff output above:
- In the unpatched DLL, if we check carefully we can see that there is a call to “GetuntrimmedCharacterCount” function and later on there is another call to a function “SetSpan::SpanVector”
- In the patched DLL, we can see that there is a call to “GetuntrimmedCharacterCount” where a return value stored inside EAX register is checked. If it’s zero, then control jumps to another location—a destructor for BuiltLine Object, this was newly added code in the patched DLL:
So we can assume that this is where the vulnerability is fixed. Now we need to figure out following:
- Why our program is crashing with the provided POC file?
- What field in the file is causing this crash?
- What value of the field?
- Which condition in program which is causing this crash?
- How this was fixed?
EMF File Format:
EMF is also known as enhanced meta file format which is used to store graphical images device independently. An EMF file is consisting of various records which is of variable length. It can contain definition of various graphic object, commands for drawing and other graphics properties.
Credit: MS EMF documentation.
Generally, an EMF file consist of the following records:
-
EMF Header – This contains information about EMF structure.
-
EMF Records – This can be various variable length records, containing information about graphics properties, drawing order, and so forth.
-
EMF EOF Record – This is the last record in EMF file.
Detailed specifications of EMF file format can be seen at Microsoft site at following URL:
https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-emf/91c257d7-c39d-4a36-9b1f-63e3f73d30ca
Locating the Vulnerable Record in the EMF File:
Generally, most of the issues in EMF are because of malformed or corrupt records. We need to figure out which record type is causing this crash. For this if we look at the call stack we can see following:
We can notice a call to function “gdiplus!GdipPlayMetafileRecordCallback”
By setting a breakpoint on this function and checking parameter, we can see following:
We can see that EDX contains some memory address and we can see that parameter given to this function are: 00x00401c,0x00000000 and 0x00000044.
Also, on checking the location pointed by EDX we can see following:
If we check our POC EMF file, we can see that this data belongs to file from offset: 0x15c:
By going through EMF specification and manually parsing the records, we can easily figure out that this is a “EmfPlusDrawString” record, the format of which is shown below:
In our case:
Record Type = 0x401c EmfPlusDrawString record
Flags = 0x0000
Size = 0x50
Data size = 0x44
Brushid = 0x02
Format id = 0x01
Length = 0x14
Layoutrect = 00 00 00 00 00 00 00 00 FC FF C7 42 00 00 80 FF
String data =
Now that we have located the record that seems to be causing the crash, the next thing is to figure out why our program is crashing. If we debug and check the code, we can see that control reaches to a function “gdiplus!FullTextImager::BuildAllLines”. When we decompile this code, we can see something like this:
The following diagram shows the function call hierarchy:
The execution low in summary:
- Inside “Builtline::BuildAllLines” function, there is a while loop inside which the program allocates 0x60 bytes of memory. Then it calls the “Builtline::BuiltLine”
- The “Builtline::BuiltLine” function moves data to the newly allocated memory and then it calls “BuiltLine::GetUntrimmedCharacterCount”.
- The return value of “BuiltLine::GetUntrimmedCharacterCount” is added to loop counter, which is ECX. This process will be repeated until the loop counter (ECX) is < string length(EAX), which is 0x14 here.
- The loop starts from 0, so it should terminate at 0x13 or it should terminate when the return value of “GetUntrimmedCharacterCount” is 0.
- But in the vulnerable DLL, the program doesn’t terminate because of the way loop counter is increased. Here, “BuiltLine::GetUntrimmedCharacterCount” returns 0, which is added to Loop counter(ECX) and doesn’t increase ECX value. It allocates 0x60 bytes of memory and creates another line, corrupting the data that later leads the program to crash. The loop is executed for 21 times instead of 20.
In detail:
1. Inside “Builtline::BuildAllLines” memory will be allocated for 0x60 or 96 bytes, and in the debugger it looks as follows:
2. Then it calls “BuiltLine::BuiltLine” function and moves the data to newly allocated memory:
3. This happens in side a while loop and there is a function call to “BuiltLine::GetUntrimmedCharacterCount”.
4. Return value of “BuiltLine::GetUntrimmedCharacterCount” is stored in a location 0x12ff2ec. This value will be 1 as can be seen below:
5. This value gets added to ECX:
6. Then there is a check that determines if ecx< eax. If true, it will continue loop, else it will jump to another location:
7. Now in the vulnerable version, loop doesn’t exist if the return value of “BuiltLine::GetUntrimmedCharacterCount” is 0, which means that this 0 will be added to ECX and which means ECX will not increase. So the loop will execute 1 more time with the “ECX” value of 0x13. Thus, this will lead to loop getting executed 21 times rather than 20 times. This is the root cause of the problem here.
Also after some debugging, we can figure out why EAX contains 14. It is read from the POC file at offset: 0x174:
If we recall, this is the EmfPlusDrawString record and 0x14 is the length we mentioned before.
Later on, the program reaches to “FullTextImager::Render” function corrupting the value of EAX because it reads the unused memory:
This will be passed as an argument to “FullTextImager::RenderLine” function:
Later, program will crash while trying to access this location.
Our program was crashing while processing EmfPlusDrawString record inside the EMF file while accessing an invalid memory location and processing string data field. Basically, the program was not verifying the return value of “gdiplus!BuiltLine::GetUntrimmedCharacterCount” function and this resulted in taking a different program path that corrupted the register and various memory values, ultimately causing the crash.
How this issue was fixed?
As we have figured out by looking at patch diff above, a check was added which determined the return value of “gdiplus!BuiltLine::GetUntrimmedCharacterCount” function.
If the retuned value is 0, then program xor’s EBX which contains counter and jump to a location which calls destructor for Builtline Object:
Here is the destructor that prevents the issue:
Conclusion:
GDI+ is a very commonly used Windows component, and a vulnerability like this can affect billions of systems across the globe. We recommend our users to apply proper updates and keep their Windows deployment current.
We at McAfee are continuously fuzzing various open source and closed source library and work with vendors to fix such issues by responsibly disclosing such issues to them giving them proper time to fix the issue and release updates as needed.
We are thankful to Microsoft for working with us on fixing this issue and releasing an update.
The post Analyzing CVE-2021-1665 – Remote Code Execution Vulnerability in Windows GDI+ appeared first on McAfee Blogs.
