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

How to achieve Microsoft "photos" application Raw format image encoder loophole CVE-2021-24091 technical analysis, many novices are not very clear about this, in order to help you solve this problem, the following editor will explain in detail for you, people with this need can come to learn, I hope you can get something.

Preface

In December 2020 and February 2021, Microsoft released two security updates for the Raw image encoder for the Photo app, in which CVE-2021-24091 was fixed on February 9. The author is engaged in the security research of the file format. After finding the poc provided by the researchers, the author verifies and analyzes the vulnerability.

According to information disclosed by MSRC and the flaw discoverer, the flaw lies in the correlation function of Windows Imaging Component decoding the original image captured by the Olympus E300 camera. As the Internet does not have too many public resources to introduce the E300 RAW format (the author only found a public information, see https://myolympus.org/E300/#RAW), so this paper will analyze the causes of vulnerabilities from the perspective of vulnerability generation mechanism.

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.

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

0x01 vulnerability analysis

Using ida pro to load a crashed dll, you can confirm that the crash occurred in a loop that writes data to the buffer.

Through this code, we can roughly judge that the conditional statement of the loop body leads to too many loops, resulting in out-of-bounds writing. The initialization of some variables of the function is as follows:

Combined with the initialization of local variables at the beginning of the function and the cross-reference of variables, it can be concluded that:

1. By reading the member value of a certain type of object and calculating it, the code calculates the size of the buffer that needs to be applied for.

2. The buffer is divided into two parts, one is a data block (chunk2) whose size is * (this+12320*4) * 2, and the other is a data block (chunk1) whose size is * (this+0x12320*4) * 16 / 10 bytes.

3. After initialization, the code first executes a for loop, executes another for loop inside the body of the loop, and writes data to the chunk2.

So, the pseudo code for this code is as follows:

Chunk2_size = this- > mem_12320;chunk1_size = chunk2_size * 16 / 10 * data = (char *) malloc (chunk1_size + 2 * chunk2_size); for (char * I = data+chunk1_size; v12)

< this->

Mem_12325; a5 = v12) {… Expresions;... For (char * pdata = data, char * j = I; j

< chunk+chunk1_size+2*chunk2_size; pdata += 3, j += 4){if ((pdata - data) ) pdata++;*(word *)j = pdata[1] 4; //写入两个字节 }…expressions;…} 按照上面的伪代码，每次循环都写入四个字节，循环次数应该是(chunk2_size * 2 / 4)向上取整的值。在第一个for循环中，当 i = &data[chunk1_size]，即从第二个chunk头部开始循环写入字节时，如果chunk2_size为奇数，循环次数 * 4 将大于chunk2_size。也就是说，最后一次循环中，写入后两个字节时，将造成越界，产生访问违例。 0x02 漏洞调试 使用windbg 附加App进程，并在崩溃函数设置断点： bu WindowsCodecsRaw!COlympusE300LoadRaw::olympus_e300_load_raw 图片App 加载poc 文件时，获取的chunk2_size为0xd79,是一个奇数。 通过上文的伪代码可得： chunk1_size = 0x158e data 指向的内存区域是一个大小为0x3080的缓冲区。 代码执行到第二个for循环时，需要写入数据的指针存放在r15中，即为chunk2 缓冲区的起始地址（r15 == data + chunk1_size）： 所以，在这种情况下，循环次数应为⌈ (0xd79 * 2 / 4) ⌉，即为1725 次。而缓冲区只有2 * chunk2_size, 共6898个字节，不能支持1725*4 = 6900个字节的写入。由此可知，最后一次循环将产生两个字节的越界。至此，漏洞分析完毕。 循环次数记录如下：共命中725次，与分析无误。

0x03 about the source of this code

The discoverer of the vulnerability mentioned: through the function name search, this code is quite similar to the function of the same name in the LibRaw Lite library, but the library has stopped maintenance and update, and the source code download address is invalid, so the author found a similar code snippet on github. (https://github.com/coolshou/DIR-850L_A1/blob/92b64054ac75795429b9a6678baef5b3e69dfc10/progs.gpl/image_tools/netpbm-10.35.81/converter/other/cameratopam/camera.c)

By comparison, this code is basically consistent with the implementation of the vulnerability function, so Microsoft's code should be reimplemented on this basis.

Therefore, based on the consideration of code supply chain security, it is recommended to use the code of LibRaw Lite library function and let the relevant personnel update the patch by themselves.

0x04 Microsoft Code Patch

The official patch released by Microsoft on February 9 is as follows:

This patch is simple and crude, that is, when you copy the second pixel (the second time you write a double byte), determine whether the pointer points to the end of the buffer.

Is it helpful for you to read the above content? If you want to know more about the relevant knowledge or read more related articles, please follow the industry information channel, thank you for your support.

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.