Deep Analysis of Microsoft Office RTF File Stack Overflow Vulnerability (CVE-2016-0010)

Deep Analysis of Microsoft Office RTF File Stack Overflow Vulnerability (CVE-2016-0010)

0 × 01 Summary
In this month's Microsoft Tuesday patch, Microsoft fixed 3 Office vulnerability MS16-004. This vulnerability is a heap overflow vulnerability caused by the failure of MS Office to correctly parse the RTF document. Successful exploitation of this vulnerability allows attackers to remotely execute code. The root cause is that the heap overflow can be caused by controlling the length of the copy to the heap buffer. This article will analyze it.
0 × 02 Analysis
Open the constructed RTF file. The Word crash information is as follows:

First, let's take a look at this RTF file. Compare the minimum POC file with the normal file, and you will find that there is a difference in the offset value 0x1733D. The comparison is as follows:

Figure 1. Comparison between normal RTF files and POC files
As shown in figure 1, the difference lies in the structure:

The original file structure is as follows:

It is obvious that the vulnerability caused by word processing the "pict" structure in the RTF file.
A Brief Introduction to the RTF file format. For details, refer to the official website. The RTF file is usually encoded in seven digits and consists of control characters, controllers, and groups. The RTF control word is a special command used to mark the print control character and manage document information. A control word cannot exceed 32 characters. The format of the control word is as follows: \ letter sequence.
Here we only need to focus on the control word "\ pict ". An RTF file can contain images created by other applications. These images can be in hexadecimal (default) or binary format. The image is a target reference and starts with the \ pict control word. An image reference has the following syntax:

The following table lists the definitions of these control words:


In the POC file, the "\ dibitmap0" and "\ wbmwidthbytes16" control words are used.

According to the definition of "\ dibitmapN", the image source is a Windows Device-Independent Bitmap information contained in the RTF, which is derived from the BITMAPINFO structure before the actual pixel data. The question is, how does the metadata correspond to the BITMAPINFO structure?

We know that this is a Windows Device-Independent Bitmap. Therefore, we create a BMP file on the graphic board and parse the BMP template of 010editor to obtain the following information:

Figure 2. parse the BMP file
The BITMAPINFO structure corresponds to the following metadata. The BITMAPINFOHEADER structure data is as follows, with a length of 0 × 028.

The BITMAPLINE structure data is as follows, with a length of 0 × 10.

Now, replace the BITMAPINFOHEADER structure data in the POC file with the above data to obtain the combined BMP file, as shown below:

Figure 3. parse the combination and embed the BMP bitmap in the RTF File