{"id":96543,"date":"2019-08-28T08:06:19","date_gmt":"2019-08-28T15:06:19","guid":{"rendered":"https:\/\/securingtomorrow.mcafee.com\/?p=96543"},"modified":"2025-05-27T20:19:22","modified_gmt":"2025-05-28T03:19:22","slug":"analyzing-and-identifying-issues-with-the-microsoft-patch-for-cve-2018-8423","status":"publish","type":"post","link":"https:\/\/www.mcafee.com\/blogs\/other-blogs\/mcafee-labs\/analyzing-and-identifying-issues-with-the-microsoft-patch-for-cve-2018-8423\/","title":{"rendered":"Analyzing and Identifying Issues with the Microsoft Patch for CVE-2018-8423"},"content":{"rendered":"

Introduction<\/h2>\n

As of July 2019, Microsoft has fixed around 43 bugs in the Jet Database Engine. McAfee has reported a couple of bugs and, so far, we have received 10 CVE\u2019s from Microsoft<\/a>. In our previous post<\/a>, we discussed the root cause of CVE-2018-8423. While analyzing this CVE and patch from Microsoft, we found that there was a way to bypass it which resulted in another crash. We reported it to Microsoft and it fixed it in the January 19 patch Tuesday. This issue was assigned CVE-2019-0576. We recommend our users to install proper patches and follow proper patch management policy and keep their windows installations up to date.<\/p>\n

In this post we will do the root cause analysis of CVE-2019-0576. To exploit this vulnerability, an attacker needs to use social engineering techniques to convince a victim to open a JavaScript file which uses an ADODB connection object to access a malicious Jet Database file. Once the malicious Jet Database file is accessed, it calls the vulnerable function in msrd3x40.dll which can lead to exploitation of this vulnerability.<\/p>\n

Background<\/h2>\n

As mentioned in our previous post<\/a>, CVE-2018-8423 can be triggered using a malicious Jet Database file and, as per the analysis, this issue was in the index number field. If the index number was too big the program would crash at the following location:<\/p>\n

\"\"<\/p>\n

Here, ecx contains the malicious index number. On applying the Microsoft patch for CVE-2018-8423 we can see that, on opening this malicious file, we get the following error which denotes that the issue is fixed, and the crash does not occur anymore:<\/p>\n

<\/p>\n

 <\/p>\n

Analyzing the Patch<\/h2>\n

We decided to dig deeper and see exactly how this issue was patched. On analyzing the \u201cmsrd3x40!TblPage::CreateIndexes\u201d function, we can see that there is a check to see if \u201cIndexNumber\u201d is greater than 0xFF, or 256, as can be seen below:<\/p>\n

\"\"<\/p>\n

 <\/p>\n

Here, the ecx which contains the index number has the malicious value of \u201c00002300\u201d and it is greater than 0xFF. If we see the code, there is a jump instruction. If we follow this jump instruction, we reach the following location:<\/p>\n

\"\"<\/p>\n

We can see that there is a call to the \u201cmsrd3x40!Err::SetError\u201d function, meaning the malicious file will not be parsed if the index value is greater than 0xFF and the program will give the error message \u201cUnrecognized database format\u201d and terminate.<\/p>\n

Finding Another Issue with the Patch<\/h2>\n

By looking at the patch, it was obvious that program will terminate if the index value is greater than 0xFF, but we decided to try it with an index value \u201c00 00 00 20\u201d which is less than 0xFF, and we got another crash in the function \u201cmsrd3x40!Table::FindIndexFromName\u201d, as can be seen below:<\/p>\n

\"\"<\/p>\n

Finding the Root Cause of the New Issue<\/h2>\n

As we know, if we give any index value which is less then 0xFF, we get a crash in the function \u201cmsrd3x40!Table::FindIndexFromName\u201d, so we decided to analyze it further to find out why that is happening.<\/p>\n

The crash is at the following location:<\/p>\n

\"\"<\/p>\n

It seems that program is trying to access location \u201c[ebx+eax*4+574h]\u201d but it is not accessible, meaning it is an Out of Bound Read issue.<\/p>\n

This crash looks familiar as it was also seen in CVE-2018-8423, except that it was an Out of Bound Write, while this seems to be an Out of Bound Read. If we look at eax it contains \u201c0055b7a8\u201d which, when multiplied by 4, becomes a very large value.<\/p>\n

If we look at the file it looks like this:<\/p>\n

\"\"<\/p>\n

As can be seen in below image, if we parse this file, this value of \u201c00 00 00 20\u201d (in little endian from the above image), denotes the number of an index whose name is \u201cParentIDName\u201d:<\/p>\n

\"\"<\/p>\n

Looking at the debugger at the point of the crash, it seems that ebx+574h points to a memory location and eax contains an index value which is getting multiplied by 4. Now we need to figure out the following:<\/p>\n

    \n
  1. What will be the value of eax that will cause the crash? We know that it should be less than 0xFF. But what would be the lowest value?<\/li>\n
  2. What is the root cause of this issue?<\/li>\n<\/ol>\n

    On setting a breakpoint on \u201cmsrd3x40!Table::FindIndexFromName\u201d and changing the index number to \u201c0000001f\u201d, (which does not cause a crash but helps with the debugging and understanding the program flow) we can see that edx contains the pointer to an index name which, in this case, is \u201cParentIdName\u201d:<\/p>\n

    \"\"<\/p>\n

    Debugging further we can see that the eax value comes from [ebp] and the ebp value comes from [ebx+5F4h] as can be seen below:<\/p>\n

    \"\"<\/p>\n

    When we look at \u201cebx+5F4\u201d we can see the following:<\/p>\n

    \"\"<\/p>\n

    We can see that \u201cebx+5F4<\/strong><\/span>\u201d contains the index number for all the indexes in the file. In our case the file has two indexes and their number are \u201c00 00 00 01\u201d and \u201c00 00 00 1f\u201d. If we carefully review the memory we can figure out that the maximum number of indices which can be stored here are 0x20, or 32:<\/p>\n

    Start location: 00718d54<\/p>\n

    Each index number is 4 bytes long. So 0x20*4 + 00718d54 = 00718DD4<\/p>\n

    After this, if we look at ebx+574+4<\/span>,<\/strong> we can see that it contains the pointer to index names:<\/p>\n

    \"\"<\/p>\n

    So, the overall memory structure is like this:<\/p>\n

    \"\"<\/p>\n

    There are only 0x80 or 128 bytes available to save index name pointer at location EBX+574. Each pointer gets saved at an index number location, i.e. for index number 1 it will be saved at EBX+574+1*4, the location for index number 2 will be saved at EBX+574+2*4 and so on. (index number starts from 0).<\/p>\n

    In this case, if we give an index number which is more than 31, the program will overwrite data past 0x80 bytes, which will be at the start of the EBX+5F4 location, which is the index number from the malicious file. So, in this case, if we give the value \u201c00 00 00 20\u201d instead of \u201c00 00 00 1f\u201d, it will overwrite the index number at the EBX+5F4 location, as can be seen below:<\/p>\n

    \"\"<\/p>\n

    Now the program tries to execute this instruction in \u201cmsrd3x40!Table::FindIndexFromName\u2019<\/p>\n

    Mov ecx, dword ptr [ebx+eax*4+574h]<\/p>\n

    Here, eax contains the index number which should be \u201c00 00 00 01\u201d but, since it is overwritten by \u201c0055b7a8\u201d which is a memory address, on multiplying it with 4, it becomes a huge number and then 574h is getting added to it. So, if that memory area does not exist and the program tries to read from that memory, we get an access violation error.<\/p>\n

    So, to answer the questions we had:<\/p>\n

      \n
    1. Any value which is less then 0xFF and greater then 0x31 will cause a crash if the resulting memory location from [ebx+eax*4+574h] is not accessible.<\/li>\n
    2. The root cause is that an index number is getting overwritten by a memory location, causing invalid memory access in this case.<\/li>\n<\/ol>\n

      How is it Fixed by Microsoft in the Jan 19 Patch?<\/h2>\n

      We again decided to analyze the patch to see how this issue was fixed. As is clear from the analysis, any value which is greater than or equal to 0x20 or 32 still causes a crash so, ideally, the patch should be checking this. Microsoft has added this check in the Jan 19 patch release, as can be seen below:<\/p>\n

      \"\"<\/p>\n

      As can be seen in the above image, eax hold the index value here and it is compared with 0x20. If it is more than or equal to 0x20 the program jumps to location 72fe1c00. If we go to that location, we can see the following:<\/p>\n

      \"\"<\/p>\n

      As can be seen in the above image, it calls the destructor and then calls msrd3x40!Err::SetError function and returns. So, the program will display a message saying, \u201cUnrecognized database format\u201d and then terminate.<\/p>\n

      Conclusion<\/h2>\n

      We reported this issue to Microsoft in October 2018 and it fixed this issue in the Jan 19 patch Tuesday. It was assigned CVE-2019-0576 to this issue. We recommend our users keep their Windows installations up to date and install vendor patches on a regular basis.<\/p>\n

      McAfee Coverage:<\/h2>\n

      McAfee Network Security Platform customers are protected from this vulnerability by Signature IDs 0x45251700 \u2013 HTTP: Microsoft JET Database Engine Remote Code Execution Vulnerability (CVE-2018-8423) and 0x4525890 – HTTP: Microsoft JET Database Engine Remote Code Execution Vulnerability (CVE-2019-0576).<\/p>\n

      McAfee AV detects the malicious file as BackDoor-DKI.dr .<\/p>\n

      McAfee HIPS, Generic Buffer Overflow Protection (GBOP) feature will often cover this, depending on the process used to exploit the vulnerability.<\/p>\n

      References<\/strong><\/h2>\n