The Security Implications of an Apparent Memory Leak in the Microsoft Access Database

Editor’s note: Thanks to Mimecast Research Labs’ Ofir Shlomo and Tal Dery for this discovery.

In January 2019, Mimecast Research Labs discovered and disclosed CVE-2019-0560, a Microsoft Office product vulnerability. Recently the Lab discovered and disclosed a startlingly similar new vulnerability called MDB Leaker that required a patch (CVE-2019-1463) in Microsoft’s Access database application on December 10, 2019.

If this vulnerability is left unpatched, it could leave 85,000 companies – nearly 60% of which are in the U.S. – exposed to a leak of sensitive data. As of this date of this blog, however, the Lab is not aware of any actual compromise based on this vulnerability.

How are these two vulnerabilities similar? Because of how a common coding error - in this case the improper management of system memory by an application, which could lead to the unintended disclosure of sensitive or private information.

False Positives Can be Good

While false negatives such as missing malicious files or emails should always be minimized, counterintuitively, not all false positives are inherently bad. For instance, with MDB Leaker, as with the January 2019 Microsoft Office vulnerability, the report of a potential false positive proved to be critical to this discovery. Here’s how.

After receiving a false positive report for a particular Microsoft Access file flagged through static file analysis, Mimecast researchers determined that there were code fragments in what should clearly be a data-only file type, a Microsoft Access MDB file. From there, the team suspected improperly-managed system memory in the Microsoft Access application, and they were able to determine that it was a reproducible error that was included in multiple older versions of the Microsoft Access database application.

What is the Security Vulnerability?

MDB Leaker appears to be nearly identical to the broader Office memory leak discovered by the Lab in early in 2019, which cause the content of uninitiated memory elements to be saved into every file - at least since Access 2002 - that was saved with an unpatched version of Microsoft Access database. While in many cases, due to the randomness of memory content at play here, the data unintentionally saved into the file could often be valueless content fragments. However, this might not always be necessarily true.

In some cases, the unintended data saved into the MDB file may have been sensitive information such as passwords, certificates, web requests, and domain/user information. In other words, a memory link isn’t inherently a security vulnerability; instead, it’s what the memory leak can lead to that is the actual problem. With that in mind, the Lab encourages all users of the Microsoft Access database to review the disclosure.

Consider another example from researchers. If a malicious actor was able to get on a machine which contained MDB files or could get ahold of large drops of MDB files, the actor could conduct an automated “dumpster diving” hunt through all of them to look for and collect sensitive information residing in these files that could be applied in any number of malicious uses.

Fortunately, to date, Mimecast Research Lab has not seen an exploit of this vulnerability in the wild, but a user that does not patch the potential vulnerability could be susceptible to an attack. To avoid this, follow security best practices set forth below, and patch Microsoft Access database executables as soon as possible.

Suggested Security Best Practices

Use an email security system with sophisticated malware detection capabilities which includes both static file analysis as well as sandboxing to filter malicious files from entering the organization as well as sensitive content from leaving.

Regularly monitor and install patches and updates to your IT systems and applications for security vulnerabilities as they are provided by the IT vendor.

Monitor network traffic for connections to likely command-and-control services and for the exfiltration of potentially sensitive files.

Continuously update endpoint security system to increase the likelihood of detecting malicious software running on these hosts.

This Blog is for general information purposes only, and should not be used as a substitute for consultation with professional advisors. Mimecast Services Limited and its affiliates (collectively, “Mimecast”) have exercised reasonable care in the collecting, processing, and reporting of this information but have not independently verified, validated, or audited the data to verify the accuracy or completeness of the information. Mimecast shall not be responsible for any errors or omissions contained on this Blog, and reserves the right to make changes anytime without notice. Mention of non-Mimecast products or services is provided for informational purposes only and constitutes neither an endorsement nor a recommendation by Mimecast. All Mimecast and third-party information provided in this Blog is provided on an “as is” basis. MIMECAST DISCLAIMS ALL WARRANTIES, EXPRESSED OR IMPLIED, WITH REGARD TO ANY INFORMATION (INCLUDING ANY SOFTWARE, PRODUCTS, OR SERVICES) PROVIDED IN THIS RESEARCH PAPER, INCLUDING THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE, AND NON-INFRINGEMENT. Some jurisdictions do not allow the exclusion of implied warranties, so the above exclusion may not apply to you. In no event shall Mimecast be liable for any damages whatsoever, and in particular Mimecast shall not be liable for direct, special, indirect, consequential, or incidental damages, or damages for lost profits, loss of revenue or loss of use, cost of replacement goods, loss or damage to data arising out of the use or inability to use any Mimecast website, any Mimecast solution. This includes damages arising from use of or in reliance on the documents or information present on this Blog, even if Mimecast has been advised of the possibility of such damages.