Microsoft JET Database Engine Code Execution Vulnerability

This June, FortiGuard Labs researcher Honggang Ren discovered a code execution vulnerability in the Windows JET Database Engine and reported it to Microsoft using the responsible disclosure process. On the patch Tuesday of September 2018, Microsoft released a Security Advisory that contains the fix for this vulnerability, identifying it as CVE-2018-8392.

The Microsoft JET Database Engine is a database engine on which several Microsoft products have been built. A database engine is the underlying component of a database, a collection of information stored on a computer in a systematic way.

The vulnerable DLL msexcl40.dll identified by FortiGuard Labs is a component of all supported Windows versions, from Windows 7 to Windows 10 and can be triggered with a crafted Excel file. When this PoC file is parsed by Excel as external data source created by a JET OLEDB data connection, a memory copy operation (memcpy function call) with an incorrect length is executed. As a result, the destination variable (pointer) is overwritten due to a buffer overflow caused by improper bounds checking. Then, during the next memcpy function call, the overwritten destination variable (destination buffer) results in an arbitrary memory address write.

In this blog we will share our detailed analysis of this vulnerability.

Analysis

To reproduce this vulnerability, we need to open the JET OLEDB external data source in Excel with the following parameters. The PoC file “03.xls” can be located in a local folder or SMB share. Once this is done, we can see that Excel crashes. 

The 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 “msexcl40!memcpy”, which is called by the function “msexcl40!ExcelMIReadRecord”. The destination memory address sent to memcpy is 0x760061, which is an inaccessible address by any program.

Through reverse engineering and tracing we can see that the destination memory address is taken from the global variable _pExcelRecordBuffer. This global variable is located at .data:658B2CC0.

By further reverse engineering and tracing, we finally see that the call of the function     ProcessWriteAccessRecord, and its child function _ExcelExtractString, results in the overwriting of the global variable _pExcelRecordBuffer due to the buffer overflow. In the _ExcelExtractString function, the real destination buffer of memcpy is the global variable _ExcelRecordTextBuffer, which has the address of 0x658B28C0. Due to the wrong memory copy size received from the crafted PoC file, the normal size 0x0C is changed to the wrong size of 0x100C. This results in the overwriting of the global variable _pExcelRecordBuffer, which is located at .data:658B2CC0.

The distance between the two adjacent variable addresses is only 0x400 bytes (0x658B2CC0 - 0x658B28C0 = 0x400). So, if the memory copy function is called with size 0x100C and destination address 0x658B28C0, the value of the key global variable _pExcelRecordBuffer is overwritten.

Following is the assembly code of _ExcelExtractString.

.text:6587B720 ; int __stdcall ExcelExtractString(int, int, void *Dst, int cchWideChar, LPCSTR lpMultiByteStr, int cbMultiByte)

.text:6587B720 _ExcelExtractString@24 proc near        ; CODE XREF: DispatchLabelRecord+8A↑p

.text:6587B720                                    ; ExcelExtractBigString(x,x,x,x,x)+3C↑p ...

.text:6587B720

.text:6587B720 arg_0           = dword ptr  4

.text:6587B720 arg_4           = dword ptr  8

.text:6587B720 Dst             = dword ptr  0Ch

.text:6587B720 cchWideChar     = dword ptr  10h

.text:6587B720 lpMultiByteStr  = dword ptr  14h  --> this parameter is taken from the PoC file at offset 0x22A.

To clearly see what is in the overwritten buffer, we paste the buffer content as follows: (the buffer contents are all taken from the PoC file, but they are not continuous in the PoC file)

.text:6587B720 cbMultiByte     = dword ptr  18h  --> this parameter is from the PoC file at offset 0x228, and it is the memory copy size. Due to the crafted PoC, the copy size is wrongly set to 0x100C (the correct value should be only 0x0C). Due to an insufficient bounds check, this results in following buffer overflow.

.text:6587B720

.text:6587B720                 cmp     [esp+arg_0], 8

.text:6587B725                 push    esi             ;

.text:6587B726                 mov     esi, [esp+4+Dst] ;

.text:6587B72A                 push    edi

.text:6587B72B                 jge     short loc_6587B74A ;

.text:6587B72D                 push    [esp+8+cchWideChar] ; cchWideChar

.text:6587B731                 mov     eax, [esp+0Ch+arg_4]

.text:6587B735                 push    esi             ; lpWideCharStr

.text:6587B736                 push    [esp+10h+cbMultiByte] ; cbMultiByte

.text:6587B73A                 push    [esp+14h+lpMultiByteStr] ; lpMultiByteStr

.text:6587B73E                 push    0               ; dwFlags

.text:6587B740                 cmp     eax, 4B0h

.text:6587B745                 jz      short loc_6587B7BF

.text:6587B747                 push    eax

.text:6587B748                 jmp     short loc_6587B7C1

.text:6587B74A ; ---------------------------------------------------------------------------

.text:6587B74A

.text:6587B74A loc_6587B74A:                       ; CODE XREF: ExcelExtractString(x,x,x,x,x,x)+B↑j

.text:6587B74A                 mov     ecx, [esp+8+lpMultiByteStr]

.text:6587B74E                 mov     al, [ecx]

.text:6587B750                 inc     ecx

.text:6587B751                 cmp     al, 1

.text:6587B753                 jnz     short loc_6587B775 ;

.text:6587B755                 mov     edi, [esp+8+cbMultiByte]

.text:6587B759                 lea     eax, [edi+edi]

.text:6587B75C                 push    eax             ; Size

.text:6587B75D                 push    ecx             ; Src

.text:6587B75E                 push    esi             ; Dst

.text:6587B75F                 call    _memcpy

.text:6587B764                 add     esp, 0Ch

.text:6587B767                 lea     eax, [edi+edi]

.text:6587B76A                 xor     ecx, ecx

.text:6587B76C                 mov     [eax+esi], cx

.text:6587B770                 pop     edi

.text:6587B771                 pop     esi

.text:6587B772                 retn    18h

.text:6587B775 ; ---------------------------------------------------------------------------

.text:6587B775

.text:6587B775 loc_6587B775:                           ; CODE XREF: ExcelExtractString(x,x,x,x,x,x)+33↑j

.text:6587B775             test    al, al

.text:6587B777             jnz     short loc_6587B7A5

.text:6587B779             mov     edi, [esp+8+cbMultiByte] ;  --> this is the crafted memory copy size edi=0x100C

.text:6587B779             ; 0:000> db

.text:6587B779             ; 01499c7e  68 61 76 65 20 65 6e 6f-75 67 68 20 74 69 6d 65  have enough time

.text:6587B779             ; 01499c8e  20 77 69 74 68 20 79 6f-75 72 20 66 61 6d 69 6c   with your famil

.text:6587B779             ; 01499c9e  79 2e 2a 00 00 79 6f 75-20 61 63 68 69 65 76 65  y.*..you achieve

.text:6587B779                                         ; "

.text:6587B77D                 mov     edx, esi

.text:6587B77F                 test    edi, edi

.text:6587B781                 jle     short loc_6587B7C9

.text:6587B783                 push    ebx

.text:6587B784                 mov     ebx, edi

.text:6587B786

.text:6587B786 loc_6587B786:                           ; CODE XREF: ExcelExtractString(x,x,x,x,x,x)+74↓j

.text:6587B786                 movzx   eax, byte ptr [ecx]

.text:6587B789                 lea     edx, [edx+2]

.text:6587B78C                 mov     [edx-2], ax   --> this is where the key global variable pExcelRecordBuffer is overwritten. Its value is then changed to 0x760061.

.text:6587B790                 lea     ecx, [ecx+1]

.text:6587B793                 dec     ebx

.text:6587B794                 jnz     short loc_6587B786

...

The following is the disassembly code at the final crash point caused by the key global variable being overwritten:

.text:65887D40 ; __stdcall ExcelMIReadRecord(x, x, x)

.text:65887D40 _ExcelMIReadRecord@12 proc near         ; CODE XREF: ExcelReadTotalRecord(x,x,x)+33↑p

.text:65887D40

.text:65887D40 arg_0           = dword ptr  4

.text:65887D40 arg_8           = dword ptr  0Ch

.text:65887D40

.text:65887D40                 mov     eax, [esp+arg_0]

.text:65887D44                 push    esi

.text:65887D45                 push    edi             ;

.text:65887D46                 mov     edi, [eax+28h]

.text:65887D49                 mov     eax, [edi+8]

.text:65887D4C                 movsx   esi, word ptr [eax+6]

.text:65887D50                 cmp     esi, _g_cbCurrentSize

.text:65887D56                 jbe     short loc_65887D85  ------> jump here

.text:65887D58                 push    esi             ; Size

.text:65887D59                 push    _pExcelRecordBuffer ; Src

.text:65887D5F                 call    _MemReAllocate@8 ; MemReAllocate(x,x)

.text:65887D64                 mov     edx, eax

.text:65887D66                 mov     _pExcelRecordBuffer, edx

.text:65887D6C                 test    edx, edx

.text:65887D6E                 jnz     short loc_65887D7D

.text:65887D70                 pop     edi

.text:65887D71                 mov     _g_cbCurrentSize, eax

.text:65887D76                 lea     eax, [edx-2]

.text:65887D79                 pop     esi

.text:65887D7A                 retn    0Ch

.text:65887D7D ; ---------------------------------------------------------------------------

.text:65887D7D

.text:65887D7D loc_65887D7D:                           ; CODE XREF: ExcelMIReadRecord(x,x,x)+2E↑j

.text:65887D7D                 mov     _g_cbCurrentSize, esi

.text:65887D83                 jmp     short loc_65887D8B

.text:65887D85 ; ---------------------------------------------------------------------------

.text:65887D85

.text:65887D85 loc_65887D85:                           ; CODE XREF: ExcelMIReadRecord(x,x,x)+16↑j

.text:65887D85                 mov     edx, _pExcelRecordBuffer --> this is the value of the overwritten global variable, with the arbitrary address assigned to edx

.text:65887D8B

.text:65887D8B loc_65887D8B:                           ; CODE XREF: ExcelMIReadRecord(x,x,x)+43↑j

.text:65887D8B                 mov     ecx, [edi+8]

.text:65887D8E                 movsx   eax, word ptr [ecx+6]

.text:65887D92                 push    eax             ; Size

.text:65887D93                 lea     eax, [ecx+8]

.text:65887D96                 push    eax             ; Src

.text:65887D97                 push    edx             ; Dst

.text:65887D98                 call    _memcpy         ; ----> this is where memcpy with an arbitrary destination address occurs

.text:65887D9D                 mov     ecx, [esp+14h+arg_8]

From the above analysis, we can see that the root cause of this vulnerability is the malformed size value 0x100C, which is located in the PoC file at offset 0x228. The proper value should be 0x0C. Due to insufficient bounds check, the malformed size value results in the overwriting of a key neighbor global variable in the memcpy function call. Then, in next memcpy function call, the overwritten global variable with an arbitrary value is used in memory copy as the destination address, which results in a code execution condition. Successful exploitation of this vulnerability could lead to remote code execution.

Solution

All users of the vulnerable Microsoft Windows are encouraged to upgrade to the latest Windows version.

Additionally, organizations that have deployed Fortinet IPS solutions are already protected from this vulnerability with the signature MS.JET.Database.Engine.Remote.Code.Execution.