Threat Research

Microsoft Windows JET Database Engine Heap Overflow Vulnerability

By Honggang Ren | April 11, 2018

At the end of 2017, the FortiGuard Labs team discovered a heap overflow vulnerability in Microsoft Windows JET Database Engine and reported it to Microsoft following Fortinet’s responsible disclosure process. On April 10, 2018, Microsoft released an advisory that contains the fix for this vulnerability and identifies it as CVE-2018-1003.

This heap overflow vulnerability exists in the Microsoft JET Database Engine’s dynamic link library “msexcl40.dll”, which has a long history. It was first introduced in Windows 2000, and is a component of all supported Windows versions from Windows 7 to Windows 10.

The vulnerability I discovered can be triggered with a crafted Excel file. When Excel parses the file with the external data source ODBC Connect pointing to the crafted Excel file, a heap copy operation with an incorrect length is executed. As a result, the destination heap buffer is overflowed due to an insufficient bounds check.

In this blog I want to share my detailed analysis of this vulnerability.


To reproduce this heap overflow vulnerability, you can open the ODBC external data source in Excel with the ODBC Connect string set to "DRIVER={Microsoft Excel Driver (*.xls)};DBQ=c:\poc\poc.xls". You can then see that Excel crashes as a result. The PoC file “poc.xls” can then be put into any local folder or SMB share.

Following is the call stack when the crash occurs.

Figure 1. Call stack when the crash occurs

From the above call stack output we can see that the crash occurs in the function “msexcl40!memcpy”, which is called by the function “msexcl40!ExcelMIReadRecord”.

The address of the destination heap memory is 0x0766efdc and its allocated size is 0x202C. The destination heap is allocated by calling the function RtlpAllocateHeap.

By reverse engineering and tracing, we can see that the call of the function _ExcelScanFile@12 results in a crash.

After calling the function _ExcelReadTotalRecord a number of times, the actual size of the heap copy can be determined by calculating the first parameter edi. The size is poi(poi(poi(edi+28h)+8)+4), which is a HIWORD. After tracing the program execution, we can finally see that the size of the heap copy is determined from three link list nodes in the PoC file.

Figure 2 shows the first link list node that contains the crafted data in the PoC file.

Figure 2. The first link list node in the PoC file

The crafted size value is 0x1014 ,which is highlighted in Figure 2. This allows us to get the second link list node, whose offset begins at 0x1373 + 0x1014 = 0x2387.

Figure 3. The second link list node in the PoC file

The size value of the second link list node is 0x08, which is highlighted in Figure 3. From this we can get the third link list node, whose offset begins at 0x238B + 0x08 = 0x2393.

Also from Figure 3, we can see that the size value of the third link list node is 0x2604, which is at the file offset 0x2395. This value is used as the memcpy size of the destination heap. From the above analysis we already know that the destination heap was allocated with size 0x202c (the size can be determined from “!heap -x 0x0766efdc” when the full page heap is not enabled). As a result, the heap buffer overflow occurs. 

From the above analysis, we can see the root cause of the heap overflow is the malformed size value of 0x1014 that is located at offset 0x1372 in the PoC file. The good value should be 0x14. So the malformed size value results in the wrong location of the second link list node, and the third link list node is also in a wrong location, which causes memcpy to be executed with an invalid size value of 0x2604, while the destination heap is only allocated with size 0x202c. Due to an insufficient bounds check, the heap overflow occurs. Successful exploitation of this vulnerability could lead to remote code execution.


All users of vulnerable Microsoft Windows are encouraged to upgrade to the latest Windows version or apply the latest patches. Additionally, organizations that have deployed Fortinet IPS solutions are already protected from this vulnerability with the signature



Check out our latest Quarterly Threat Landscape Report for more details about recent threats.

Sign up for our weekly FortiGuard intel briefs or to be a part of our open beta of Fortinet’s FortiGuard Threat Intelligence Service.

Join the Discussion