Research

Nov 15, 2019

NVIDIA GPU Display Drivers for Windows and GFE Software – DLL Preloading and Potential Abuses (CVE-2019-5694, CVE-2019-5695)


Introduction

SafeBreach Labs discovered two different vulnerabilities in two versions of the following products:

  1. NVIDIA GPU Display Drivers for Windows
  2. NVIDIA GFE Software

Affected versions can be found in the designated paragraph at the end of the article.

In this post, we describe the CVE-2019-5694 and the CVE-2019-5695 vulnerabilities we found in NVIDIA products. We then demonstrate how these vulnerabilities could have been exploited by an attacker during a post-exploitation phase in order to achieve persistence, whitelisting bypass and in some cases defense evasion; by using the technique of implanting an arbitrary unsigned executable which is executed by a signed service that runs as NT AUTHORITY\SYSTEM.

Note: In order to exploit this vulnerability the attacker needs to have Administrator privileges.

NVIDIA GFE / GPU Display Drivers

The components which are affected by the vulnerabilities are deployed to Windows PCs which based on different NVIDIA graphics cards, whether using the OEM’s update utility, the Windows update or the official company’s website.

Vulnerability

Discovery

In our exploration, we targeted the “NVIDIA Display Container LS” service. It seemed interesting because:

  1. We assumed that it is deployed with the NVIDIA GPU driver for Windows, therefore it could impact a lot of users who are using a PC with an NVIDIA graphics card.
  2. The executable of the service is signed by NVIDIA and if the attacker finds a way to execute code within this process, it can be used as an application whitelisting bypass which can lead to security product evasion.
  3. It runs as NT AUTHORITY\SYSTEM – the most privileged user account.
  4. This service automatically starts once the computer boots, which means that it’s a potential target for an attacker to be used as a persistence mechanism.

When the service is started, NVDisplay.Container.exe tries to load 2 missing DLL files. Each issue is relevant to a different version which we specify in the “Affected Versions” paragraph below.

  1. The first issue: It tries to load NvTelemetryAPI64.dll from a directory which doesn’t exist (C:\Program Files\NVIDIA Corporation\NvTelemetry\NvTelemetryAPI64.dll)

  1. The second issue: It tries to load cryptnet.dll from two directories before it loads the required file:
    a. C:\Program Files\NVIDIA Corporation\Display.NvContainer\cryptnet.dll

b. C:\Program Files\NVIDIA Corporation\Display\cryptnet.dll

PoC Demonstration

In order to test this vulnerability, we compiled an unsigned arbitrary DLL which writes the following to the filename of a txt file:

  1. The name of the process which loaded it
  2. The username which executed it
  3. The name of the DLL file

We then copied the DLL to the following paths and restarted the NVIDIA Display Container LS service:

Issue 1:

Issue 2:

Using both vulnerabilities, we were able to load arbitrary DLL files and execute our code within NVDisplay.Container.exe which is signed by NVIDIA Corporation and runs as NT AUTHORITY\SYSTEM.

Root Cause Analysis

First Issue (CVE-2019-5694)

Once the service is loaded, it loads NVIDIA’s nvxdapix.dll library.

The nvxdapix.dll library calls the WinAPI LoadLibraryW function in order to load the NvTelemetryAPI64.dll:

unnamed_(12).png

The root cause of this vulnerability is that no signature validation (or for that matter, any validation) is performed against the DLL file which the service tries to load (i.e. calling the WinVerifyTrust function)

The file and the folder do not exist, therefore, an attacker can create a directory and implant an arbitrary DLL and the service will load it.

Second Issue (CVE-2019-5695)

Once the service is loaded, it loads NVIDIA’s nvxdapix.dll library.

The nvxdapix.dll library calls the WinAPI WinVerifyTrust function, which eventually (after a long chain of function calls) loads the crypt32.dll library which calls to the ChainGetCryptnetModule.

The ChainGetCryptnetModule function tries to load cryptnet.dll using LoadLibraryA:

There are 2 root causes for this issue:

  1. No signature validation (or for that matter, any validation) is performed against the cryptnet DLL file.
  2. There was no concatenation of the DLL name to the System32 path, so LoadLibraryA tried to look for the DLL in other folders first.

Although this issue is caused by Microsoft’s DLL library (crypt32.dll), there are a few ways that NVIDIA could remediate this issue, for example:

Verifying the signature and loading the real cryptnet.dll from System32. This way, LoadLibraryA wouldn’t look for it and try to load it again – it would already be loaded into the process.

Potential Malicious Uses and Impact

Below we show two possible ways that an attacker can leverage these vulnerabilities which we

discovered and documented above.

Whitelisting Bypass and Defense Evasion

The vulnerability gives attackers the ability to load and execute malicious payloads within the context of an NVIDIA Corporation signed process. This ability might be abused by an attacker for different purposes such as execution and defense evasion, for example: Application Whitelisting Bypass.

Persistence Mechanism

The vulnerability gives an attacker the ability to load and execute malicious payloads in a persistent way, each time the service is being loaded. That means that once the attacker drops a malicious DLL, the service will load the malicious code each time it is restarted.

Affected Products and Versions

First Issue – CVE-2019-5694

  • NVIDIA GPU Display Driver for Windows

  • All R390 versions

Second Issue – CVE-2019-5695

  • NVIDIA GPU Display Driver for Windows

  • All R440 versions prior to 441.12

  • All R440 versions prior to 441.12
  • All R430 versions
  • All R418 versions
  • All R440 versions
  • All R418 versions

  • NVIDIA GeForce Experience (GFE) for Windows

  • All versions prior to 3.20.1

Timeline

July 10th, 2019 – SafeBreach reported two vulnerabilities to NVIDIA.

July 10th, 2019 – NVIDIA sent an initial response.

July 30th, 2019 – NVIDIA has confirmed both vulnerabilities.

Aug 23th, 2019 – NVIDIA said that they will fix the problem in November 5th.

Oct 2nd, 2019 – Status update from NVIDIA.

Oct 4th, 2019 – NVIDIA has shared the affected products and versions, and scheduled 2 CVEs and a security bulletin to be available in November 4th.

Oct 17th, 2019 – NVIDIA has issued CVE-2019-5694 and CVE-2019-5695

Oct 31st, 2019 – NVIDIA asked for more time before publishing our blog post (Until November 18th).

Oct 31st, 2019 – SafeBreach agreed to wait until November 18th.

Nov 6th, 2019 – NVIDIA published security bulletins [1] [2]

Nov 8th, 2019 – NVIDIA updated the “NVIDIA GPU Display Driver – November 2019” security bulletin [2]

References

[1] https://nvidia.custhelp.com/app/answers/detail/a_id/4860

[2] https://nvidia.custhelp.com/app/answers/detail/a_id/4907

Get the latest
research and news