Microsoft Windows JET Engine Msrd3x Code Execution Vulnerability

Threat Analysis from FortiGuard Labs

In September 2018, Fortinet’s FortiGuard Labs researcher Honggang Ren discovered a code execution vulnerability in Windows JET Engine Msrd3x40 and reported it to Microsoft by following Fortinet’s responsible disclosure process. On patch Tuesday of January 2019, Microsoft released a Security Bulletin that contains the fix for this vulnerability and identifies it as CVE-2019-0538.

The vulnerable DLL msrd3x40 is a component of all supported Windows versions from Windows 7 to Windows 10. The vulnerability we reported can be triggered with a crafted mdb file. When the mdb PoC file is parsed, a heap corruption occurs due to freeing an invalid heap address. This could result in a code execution exploit.

In this blog, we want to share our detailed analysis of this vulnerability.

Analysis

There are two methods for reproducing this vulnerability.

Method 1:

By loading the PoC file with an Excel oledb external data source using the parameter below, you can see Excel crash. The PoC file can be located in any local or smb share.

Method 2:

In Windows 10, you can execute “cscript.exe trigger.vbs” in the command window.

Following is the call stack when the crash occurs.

From the above call stack output, we can see that the crash occurs in the function “msrd3x40!free”. Let’s enable the cscript.exe full page heap via the command: “gflags /p /enable cscript.exe /full”.

Then, let’s check the cause of the heap memory free failure in the heap memory address. The memory is in MEM_RESERVE state as follows:

By reverse engineering and tracing, we can see that the crafted mdb falsely causes the call of msrd3x40.dll because the crafted mdb file header version field is 0. The normal version should be 1. The normal mdb file has the program enter the header decryption code. However, due to the crafted mdb file version field being 0, the crafted mdb file doesn’t have the header decryption completed in msjet40.dll. 

So the crafted mdb file results then in going to function msjet40!ErrOpenForeignDatabase+0x65 and calling msrd3x40.dll!ErrIsamOpenDatabase. But handling the normal mdb file would not call the msrd3x40.dll. So from here, the crafted mdb file results in it taking the wrong code branch. 

The DLL msrd3x40.dll decrypts the crafted mdb header. The data at the offset 0x42 is originally 0x86. After the RC4 decryption of the mdb header, it causes the data at the offset 0x42 to become 0. So another code branch is taken. See following code:

By now, the invalid heap memory address has still not been generated. By further reverse engineering and tracing, we find that the multiply factor used to generate the invalid heap memory is obtained from following code:

After the above Database::AssignUserNumber function is run, the key multiply factor variable [esi+6ch] equals 0x100.

Next, let’s trace the invalid heap memory generation, as follows:

In the function, [ecx+6c] is  the previously obtained key multiply factor0x100. Here, dx=0x1. After assigning the value, [ecx+eax*2+194h] is actually assigned to word 1, where the word is actually the low word of the freed invalid memory address. That is to say, before calling Database::MarkCorrupt function, the target object heap pointer is correct. After assigning value 0x1 word to the above memory address, however, the invalid heap pointer is generated. This results in freeing the invalid pointer and code execution condition.

From the above analysis, we can see the root cause of the vulnerability is the malformed mdb version value 0x00, which causes the program to take the wrong branch, and the data at the crafted mdb file offset 0x42 is 0x86 and the data at offset 0x600-0x7ff all equal 0. This results in a multiply factor being created with a 0x100 value. In next function call, the low word of the target heap address is overwritten with 1 due to the multiply factor and an invalid heap address is generated. When the invalid heap address is freed, it results in a crash. Successful exploitation of this vulnerability could lead to remote code execution.

Solution

All users of vulnerable versions of the Microsoft Windows Server are encouraged to upgrade to the latest Windows version. Additionally, organizations that have deployed Fortinet IPS solutions have been protected from this vulnerability since Oct 12, 2018 with the following signature: 

MS.JET.Database.Engine.Msrd3x.Remote.Code.Execution

More details about this zero-day discovery can be found here

Learn more about FortiGuard Labs and the FortiGuard Security Services portfolioSign up for our weekly FortiGuard Threat Brief. 

Know your vulnerabilities – get the facts about your network security. A Fortinet Cyber Threat Assessment can help you better understand: Security and Threat Prevention, User Productivity, and Network Utilization and Performance.

Read about the FortiGuard Security Rating Service, which provides security audits and best practices.

Fortigate is an enterprise network security appliance that works with Cloud Bare Metal. Contact us to find out our latest offers!

Comments are closed.

>
%d bloggers like this: