In the last article “Technical Analysis of Microsoft” Photo “Application Raw format Image encoder Vulnerability (CVE-2021-24091)”, based on the author’s superficial understanding of Olympus E300 camera Raw format, The two image decoding libraries, WindowsCodecsRaw and WindowsCodecs, are not debugged in depth. In this article, I will analyze another vulnerability in the same library (cve-2020-17113) to deepen my understanding of the WindowsCodecsRaw library.

Based on the information made public by MSRC and the vulnerability finder, the Windows Imaging Component can trigger the sub over the raw data when it can decode the TIFF image. (See Wikipedia for TIFF format). This paper will be based on the understanding of TIFF format and combined with POC format analysis to carry out analysis for readers’ reference.

0x00 Vulnerability verification

  1. In Win10 1903 X64, use gFlags tool to open the page heap for picture app, double click the picture file to open (picture default application is photo app). After a period of time, the App exits the process.

  2. Use the Windbg Attached Photos App (see The Microsoft documentation for Windbg UWP debugging method), hit G to run the program. After some time, the process crashes. As shown below:

Combining the instructions for the access violation with the results of memory allocation, it can be concluded that the reason for the access violation is that data offset 0x30 is read in a memory region of size 0x10 bytes, and therefore it is an out-of-bounds read vulnerability.

2021 full set of network security information package and the latest interview questions (penetration tools, environment building, HTML, PHP, MySQL basic learning, information collection, SQL injection,XSS, CSRF, brute force cracking, etc.)

0x01 Vulnerability Analysis

First, IDA Pro was used to load the crashed DLL, locate the crash point, and analyze the function code.

The function declaration is as follows:

__int64 __fastcall CCanonRawImageRep::GetNamedWhiteBalances(CCanonG12ImageRep *a1, __int64 a2)
Copy the code

Combined with the analysis of the input parameter type, through self-construction of the structure and virtual table positioning, the comments are given as follows:

Function pseudocode is as follows:

CTag * tag = a1->GetTags();
Copy the code

In this code, an out-of-bounds read is possible if the length of the tag_data block is less than 48 times the maximum of the first 10 members of the VEC vector. When you actually debug the code, you can see that this tag_data is really only 16 bytes long.

Therefore, when the photo App loads this image, there will be an out-of-bounds read access violation.

0x02 About POC file

It’s not hard to understand why vulnerabilities are triggered. The question is, why does this file generate such an incorrect IFD_Tag structure? Still want to start from “photo” App parsing POC file process.

As for the debugging of the parsing process, the process is more complicated, so I will not repeat it here. Here’s a summary of some of the interesting aspects of this file, just based on the file format specification.

The file content is as follows:

Readers familiar with image formats can see that this file is a TIFF format with an embedded Exif block of information.

\

For the convenience of readers unfamiliar with TIFF format, a brief description of the TIFF format structure. TIFF, also known as “label image file format”, is a kind of file information that uses label field to standardize the size, color space and so on of image. At the same time, it has good scalability, manufacturers can design “custom label” or “private label” according to their own requirements, in order to store personalized information, rich picture content

For readers to understand, the author will illustrate several important data structures in combination with poC picture content.

2.1 the head

TIff header data structure, as shown below:

  • The first two bytes specify the file byte order. “II” is the small end and “MM” is the big end.
  • The 3-4 bytes are magic values, always 0x2A, and the byte order is specified by the first two bytes;
  • 5-8 bytes specifies the offset of the first IFD, which is non-negative and cannot exceed 4G(32-bit address space, unsigned integer, bigTIFF information is not listed here).

2.2 IFD

IFD is a directory of image files. Each IFD records the attributes and data of a page of image content (as well as subIFD and other information) in the following format:

As shown in the table above, each IFD structure consists of three parts:

  • Ifd_size: 2 bytes, specifying the number of tags in the IFD
  • Tag_array: ifd_size *12 bytes, a list of tags that specify the various attributes of the image
  • Next_ifd: 4 bytes, specifying the offset of the next IFD structure, or 0 if there is no next IFD.

2.3 the TAG

The tag structure is as follows:

The TAG structure consists of four parts:

  • Tag_id: 2 bytes, specifying the ID of the object described by the tag.
  • Tag_type: 2 bytes, specifying the data type of tag_value.
  • Tag_cnt: 4 bytes Specifies the number of tag_values;
  • Tag_value (tag_value_offset): Indicates the tag_value if the size of the tag_value is less than or equal to 4 bytes. Otherwise, this field indicates the offset of the tag_value in the file.

The above is a brief description of several important data structures in TIFF format, please refer to the resources for details.

2.4 Several tag_id’s worth noting

In addition to TIFF’s basic IFD tag, there are several TAG_ID that need to be mentioned:

It is worth noting that the presence of the above ifD_tags indicates that nested IFDs are generated in the file.

2.5 IFD structure of POC files

As shown in the 010Editor template parsing of the POC file in the previous article, the image is nominally at least two pages long because the next_ifd_offset of the first IFD structure is not zero.

However, starting with offset 0x2232 indicates that the data is an invalid IFD structure, so parsing the IFD will exit because the data does not conform to the structure specification.

In the actual debugging process, the author recorded the poC file parsing process of “Photo” App by reversing the image coding library and setting breakpoints. Parsed IFD tag structure, partial output is as follows:

bu windowscodecsraw+023D3A1 "r $t1 = poi(rsi+28) ; .echo tag is:; dd rbp-cc l1; .printf "offset is %x", @$t1; .echo \n; gc"
Copy the code

As you can see, the tag value at offset 0xC6 is 0x8769, which is the Exif IFD mentioned earlier, so the photo App will continue parsing. Obviously, the POC file is mutated, and the debugging process is a bit more complicated than parsing a normal TIFF format, so I won’t go into details here.

The following table is all the “IFD” structure information parsed by “Photo” app when parsing POC files.

It is not possible to work backwards from the existing documents to deduce what the original POC document was. However, it is variation that causes the entire TIFF file to be unrecognized by the decoder, and the tag tag to be incorrectly resolved, resulting in object resolution errors when dealing with white balance, which in turn causes out-of-bounds read access violations.

The ifD_tag structure that caused an access violation because it was incorrectly resolved looks like this:

0 x03 summary

Thanks to its scalability and adaptability, Tiff is widely available in a variety of production environments. Through this vulnerability analysis, the author found some information neglected in the study of TIFF format, and also obtained some new ideas to mine the VULNERABILITY of TIFF format. If readers can get the same inspiration from this article, then the author has realized the value of sharing.