Shulou(Shulou.com)05/31 Report--

How to analyze the vulnerability of Microsoft photo application image encoder CVE-2020-17113, in view of this problem, this article introduces the corresponding analysis and solution in detail, hoping to help more partners who want to solve this problem to find a more simple and feasible method.

The author will analyze the vulnerabilities in the same library (CVE-2020-17113) in order to deepen the understanding of the WindowsCodecsRaw library.

Based on the information disclosed by MSRC and the vulnerability discoverer, the vulnerability is triggered during the parsing of the original data (GetNameWhiteBalances) when Windows Imaging Component decodes pictures in TIFF format. (see Wikipedia for TIFF format). This article will be based on the understanding of TIFF format and combined with POC format parsing analysis for readers' reference.

0x00 vulnerability verification

1. On the Win10 1903 x64 system, use the gflags tool to open the page heap for the picture app, and double-click the picture file to open it (photo App is the default application for pictures). After a period of time, App exits the process.

two。 Use Windbg to attach a photo App (see Microsoft documentation for Windbg debugging UWP method), and click g to run the program. After a while, the process crashes. As shown in the following figure:

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

0x01 vulnerability analysis

First, use ida pro to load the crash dll, locate the collapse point, and analyze the function code.

The function is declared as follows:

_ _ int64 _ _ fastcall CCanonRawImageRep::GetNamedWhiteBalances (CCanonG12ImageRep * A1, _ _ int64 a2)

Combined with the analysis of the types of incoming parameters, through the self-construction of the structure and the positioning of the virtual table, the comments are as follows:

The pseudo code of the function is as follows:

CTag * tag = A1-> GetTags (); vector vec = {0,1,2,3,4,5, … }; tag_data = tag- > GetTagdata (); for (int I = 0; I

GetTagCount () {dword * addr = tag_data + 48 * vec [I]; dword V26 = * (addr); word v13 = * (word*) (addr+4); expressions;...}. Expressions;}

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

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

0x02 about POC Fil

It is not difficult to understand the cause of the vulnerability. But the question is, why does this file produce such an incorrect IFD_Tag structure? You still need to start with the process of parsing the POC file by the Photo App.

With regard to the debugging of the parsing process, the process is relatively complicated, so I will not repeat it here. Here is a summary of some interesting phenomena shown in this file only according to the file format specification.

The contents of the file are as follows:

Readers who are familiar with the image format will find that this file is an tiff format embedded in Exif information blocks.

For the convenience of readers who are not familiar with tiff format, let's briefly talk about the structure of TIFF format. TIFF, namely "tag image file format", is a kind of file information that uses label fields to standardize the size and color space of the image. At the same time, it has good scalability, manufacturers can design "custom tags" or "private tags" according to their own needs, in order to store personalized information and enrich picture content (for more information, please see TIFF FAQ. Https://www.awaresystems.be/imaging/tiff/faq.html).

Easy for readers to understand, the author will combine the content of poc pictures to illustrate several important data structures.

2.1 head

The TIff header data structure is as follows:

The first two bytes specify the file byte order, and "II" is the small end and "MM" is the big end.

3-4 bytes are Magic values, always 0x2A, and byte order specified by the first two bytes

5-8 bytes specify the offset of the first IFD, which is non-negative and cannot exceed 4G (32-bit address space, unsigned integers, bigtiff information is not shown here).

2.2 IFD

IFD is the image file directory. Each IFD records the attributes and data of a page of image content (also records subifd and other information). The format is as follows:

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

Ifd_size:2 bytes that specify the number of tag in the IFD

Tag_array:ifd_size * 12 bytes, a list of tag that specifies the various attribute values of the picture

Next_ifd:4 bytes that specifies the offset of the next IFD structure, if there is no next IFD value of 0.

2.3 TAG

The structure of tag is as follows:

The tag structure consists of four parts:

Tag_id:2 bytes that specify the ID of the object described by the tag

Tag_type:2 bytes that specify the data type of the tag_value

Tag_cnt: 4 bytes specify the number of tag_value values

Tag_value (tag_value_offset): if the size of the tag_value value does not exceed 4 bytes, it means tag_value, otherwise this field points to the offset of the tag_value in the file.

The above is a brief description of several important data structures in TIFF format. For more information, please refer to the information yourself.

2.4 several noteworthy tag_id

In addition to TIFF's basic IFD tag, there are a few TAG_ID that need to be mentioned:

It is worth noting that when the above IFD_Tag appears, the IFD in the nested format is generated in the file.

2.5 about the IFD structure of poc files

As shown in the previous parsing of the poc file by the 010Editor template, nominally, this picture is at least two pages long because the next_ifd_offset of the first IFD structure is not 0.

However, offsetting the beginning of 0x2232 indicates that this data is an invalid IFD structure, so when parsing ifd, it will exit the parsing function because the data does not conform to the structural specification.

In the actual debugging process, the author records the parsing process of the "photo" App to the poc file by reverse image coding library and setting breakpoints. The parsed ifd tag structure, some of which are output 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"

As you can see, the tag value at the offset 0xc6 is 0x8769, which is the Exif IFD mentioned earlier, so the "photo" App continues to parse. Obviously, this poc file has been mutated, and the debugging process is a little more complicated than parsing the normal TIFF format, so I won't repeat it here.

The following table shows all the "IFD" structure information that is parsed when the Photo app parses the poc file.

The author can not reverse deduce what the poc original file is from the existing file. However, it is the mutation that causes the error that the decoder cannot recognize in the whole TIFF file, and the tag tag is parsed incorrectly, which leads to an error in object parsing when dealing with white balance, which leads to access violation of out-of-bounds reading.

The ifd_tag structure that resulted in an access violation due to incorrect parsing is as follows:

Summary of 0x03

Thanks to its good scalability and strong adaptability, Tiff is widely used in a variety of production environments. Through this vulnerability analysis, the author found some information that was ignored in the study of tiff format. At the same time, I also got a new idea of mining Tiff format loopholes. If readers can get the same inspiration from this article, the author's sharing value will be realized.

This is the answer to the question on how to analyze the vulnerability of Microsoft photo application image encoder CVE-2020-17113. I hope the above content can be of some help to you. If you still have a lot of doubts to be solved, you can follow the industry information channel for more related knowledge.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.