This post is a walkthrough on discovering multiple arbitrary file writes through the NVIDIA GeForce Experience (GFE) — CVE-2019-5674 — which is installed by default on systems running NVIDIA GeForce products. With an arbitrary file write, you can force an application to overwrite any file on the system as a privileged user. Often, this just means you can cause a denial of service by overwriting critical system files, but if you can control the data that is being written in some way, often you can do more with it.

This vulnerability allowed any system file to be overwritten due to insecure permissions set on log files which GFE writes data to as the SYSTEM user. Additionally, one log file contained data that could be user-controlled, allowing commands to be injected into it and then written to as a batch files leading to code execution on other users and potentially privilege escalation. I will also describe how this vulnerability could have been chained with a denial of service vulnerability to gain full privilege escalation.

The NVIDIA website describes GeForce Experience GFE as a way to “capture and share videos, screenshots, and livestreams with friends, and keep your drivers up to date and optimize your game settings.” Essentially, it is a supplementary application which is installed alongside GeForce products in order to give a user added functionality.

To begin to look for issues with the NVIDIA services and applications which were running I opened up Process Monitor (Procmon) and got an idea for the different application NVIDIA was running by default as part of the GeForce Experience and other services. To do this I used procmon.exe from Sysinternals. I noticed a couple processes related to NVIDIA: nvcontainer.exe and NVDisplay.Container.exe.

Now that I knew some of the processes NVIDIA was running, I added a filter to Procmon to look at the different files which were being written by *container.exe, which will cover both the processes of interest.

With the filter applied, only looking for WriteFile operations, a few suspicious items jump out. The image below shows these processes writing to a few log files as “NT AUTHORITY\SYSTEM” to “C:\ProgramData” (which often contains files normal users can modify).

Checking the permissions on some of these files shows that the “Everyone” group has full control over them.

So, the files are being written to by SYSTEM and Everyone has full control over them. The issue here is that Everyone could modify the file in any way, this includes creating hard or symbolic links to other files on the system. If I am able to create a link to another system file that I would not be able to write to as my normal user, the SYSTEM process will follow the link and be able to write to that file, thinking it is the log file it is supposed to be writing to. This could include critical system files which may make applications or the system unstable, crash or unbootable.

The symbolic and hard links needed to exploit the file write can be created using the symboliclink-testing-tools created by James Forshaw. These use some tricks to allow you to create a link to system files even as a normal user. To test this out I used the Createsymlink tool and created a temporary symlink from “C:\ProgramData\NVIDIA Corporation\nvstapisvr\nvstapisvr.log” to “C:\windows\test.file” (which is owned and only writeable by an administrator). In order to for the symlink be successful it requires the “C:\ProgramData\NVIDIA Corporation\nvstapisvr\” directory to be empty (this is because it needs to create directory junctions which require an empty directory). The error below shows what happens if the directory is not empty, followed by a successful symlink creation.

Now, when the log file “C:\ProgramData\NVIDIA Corporation\nvstapisvr\nvstapisvr.log” is written to by the NVIDIA privileged process, it actually writes to “C:\windows\test.file”.

This shows that it is possible to overwrite any file on the system. This is in itself an issue, but not quite that exciting because you cannot do much more than corrupt some files and potentially cause a DoS. This is because the data in this particular log file is not able to be controlled, it will just write whatever data is to be logged.

To make this a little more interesting I wanted to see if it was possible to control any of the data that was in the affected log files and potentially be able to do something such as write commands to a .bat file. After some poking around, I found that “C:\ProgramData\NVIDIA Corporation\nvstreamsvc\nvstreamsvcCurrent.log” contained some strings that I had seen in other files which were also writable by my normal user, “C:\ProgramData\NVIDIA Corporation\NvStreamSrv\settings.txt”. This file contained some variables which would get written to the nvstreamsvcCurrent log file whenever the “GameStream” service was toggled on and off in the GeForce Experience.

Toggling this caused the log file “C:\ProgramData\NVIDIA Corporation\nvstreamsvc\nvstreamsvcCurrent.log” to be written containing the URLs in the settings.txt.

Next, I tried appending some commands to these variables to pollute the log files.

This was successfully written to the log at “C:\ProgramData\NVIDIA Corporation\nvstreamsvc\nvstreamsvcCurrent.log”.

Now even though there is a bunch of other log data, the injected command will still eventually get executed in a .bat file.

Combining the fact that I can now write to any directory and I can inject a valid command into the vulnerable file, I should be able to write this to the system startup folder and have the command execute on any user that logs in. This would include an administrator, leading to privilege escalation.

I did run into one issue— the directory which I created the symlink from needed to be empty, but the directory contains a file which was in use by the NVIDIA service, preventing me from deleting it. This could be solved by booting into safe-mode (which is still possible as a normal user) or with the potential of chaining this with a denial of service, which will be discussed a bit more later.

Putting it all together:

• append the commands to “C:\ProgramData\NVIDIA Corporation\NvStreamSrv\settings.txt”.
• Empty the “C:\ProgramData\NVIDIA Corporation\nvstreamsvc\” directory.
• Create a symlink from “C:\ProgramData\NVIDIA Corporation\nvstreamsvc\nvstreamsvcCurrent.log” to “C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp\cmd.bat” .

Creating the symlink:

Now the “GameStream” service can be toggled on and off and you end up with a cmd.bat file in the system’s startup directory.

At this point logging in as any user will cause whatever command was injected into the log file to run on that user.

Although this was just a proof of concept to demonstrate the impact of this vulnerability, it does contain quite a few steps to achieve. I was able to identify a method of abusing this to become a full privilege escalation if it were to be chained with a denial of service on the NVIDIA .

NVIDIA has a couple batch files which can be found in “C:\Windows”.

These files are executed as SYSTEM whenever the “NVIDIA Display Container” or “NVIDIA Telemetry Container” services crash more than 2 times. This is part of the default recovery settings for the NVIDIA services. This can be seen in the following screenshot of the settings for the service.

These files could be targeted with the arbitrary file write explained in this post and then the service could be crashed 3 times to force execution of the BAT files, leading to privilege escalation.

This proof of concept demonstrates the impact that arbitrary files writes and incorrect permissions on application files can have. Often arbitrary file writes are not considered very impactful because it is assumed it can only be used to simply overwrite an arbitrary file with some data. But, if you can somehow control that data which is being written and get a little creative, the impact can be very significant. A basic proof of concept exploit demonstrating the steps in this blog can be found in our CVE-2019-5674 GitHub repo.

The original advisory from NVIDIA can be found here. This issue exists in versions of GeForce Experience prior to 3.18, so ensure you are using the latest version release from NVIDIA, which can be found here.

10/29/2018 – Issue reported to NVIDIA

11/01/2018 – Issue accepted by NVIDIA and case number created

01/11/2019 – NVIDIA informs part of the issues have been patched in GFE 3.17

03/20/2019 – NVIDIA informs the Patch for all issues was applied to GFE 3.18

03/26/2019 – NVIDIA publishes security advisory and CVE