Chaining Bugs: NVIDIA GeForce Experience (GFE) Command Execution

NVIDIA GeForce Experience (GFE) v.<= 3.21 is affected by an Arbitrary File Write vulnerability in the GameStream/ShadowPlay plugins, where log files are created using NT AUTHORITY\SYSTEM level permissions, which lead to Command Execution and Elevation of Privileges (EoP).

• NVIDIA Security Bulletin – April 2021
• NVIDIA Acknowledgements Page

Introduction

Some time ago I was looking for file system misconfigurations on common software I’ve installed on my PC when the “NvContainerLocalSystem” service, installed by default with NVIDIA GeForce, appeared on my list. Specifically, the NvContainerLocalSystem has the following properties:

Name        : NvContainerLocalSystem
DisplayName : NVIDIA LocalSystem Container
ImagePath   : 
•	"C:\Program Files\NVIDIA Corporation\NvContainer\nvcontainer.exe" -s NvContainerLocalSystem -f 
•	"C:\ProgramData\NVIDIA\NvContainerLocalSystem.log" -l 3 -d "C:\Program Files\NVIDIA 
•	Corporation\NvContainer\plugins\LocalSystem" -r -p 30000 -st "C:\Program Files\NVIDIA 
•	Corporation\NvContainer\NvContainerTelemetryApi.dll"
User        : LocalSystem
StartMode   : Automatic
Path    : C:\Program Files\NVIDIA Corporation\NvContainer\nvcontainer.exe 
IdentityReference : BUILTIN\Users
Permissions       : {WriteAttributes, AppendData/AddSubdirectory, WriteExtendedAttributes, WriteData/AddFile}
Status            : Running
UserCanStart      : True
UserCanRestart    : False

While the installation directory of the binary has the right set of permissions, checking the permissions on some of the files being written by the service showed that the “Users/Everyone” group has full control over them.

•	C:\ProgramData\NVIDIA 
•	C:\ProgramData\NVIDIA Corporation 
NT AUTHORITY\SYSTEM:(I)(OI)(CI)(F)
BUILTIN\Administrators:(I)(OI)(CI)(F)
CREATOR OWNER:(I)(OI)(CI)(IO)(F)
BUILTIN\Users:(I)(OI)(CI)(RX)
BUILTIN\Users:(I)(CI)(WD,AD,WEA,WA)

The issue here is that every logged-in user (even a low privileged one) can modify files residing in the above directories, for example creating a symbolic link to other files on the system. I won’t dive into the specific symbolic link bug class as this blog post from Almond Consulting already thoroughly explain the topic but, generally speaking: if a low-privileged user can create a symlink to a system file (that normally is not able to write), and a process running as SYSTEM write on that file, it will be instead “tricked” into following the link and writing to the destination file we specified giving us some kind of Arbitrary File Write capabilities.

Chaining Bugs

Arbitrary File Write

The first vulnerability, as mentioned before, is an Arbitrary File Write affecting the "nvstreamsvcCurrent.log" file in C:\ProgramData\NVIDIA Corporation\nvstreamsvc\nvstreamsvcCurrent.log. This file is intermittently written by the NvContainerLocalSystem service. In order to exploit this vulnerability, I've used the Createsymlink tool from the symboliclink-testing-tools suite created by James Forshaw. However, in order to be able to create the symlink, the directory must be empty as the tool needs to create a directory junction. To overcome this limitation I firstly tough of booting into safe mode (which disable non-essential windows services and drivers) and delete the folder but, inspired by Jonas L (@jonasLyk) and his blog post, I ended up following another path. NTFS rename operation can be used to move files and folder anywhere on the volume. A rename operation requires the DELETE permission on the origin and the FILE_ADD_FILE/FILE_ADD_SUBDIRECTORY permission on the destination folder (The permission on child files and folder are irrelevant). By moving all sub-folders of C:\ProgramData\NVIDIA Corporation\ into another writable location we bypass any restrictions on files inside the sub-folders. CreateSymlink.exe "C:\ProgramData\NVIDIA Corporation\nvstreamsvc\nvstreamsvcCurrent.log" c:\windows\pwned.file Now, when the service tries to write the log file, it instead follows the symlink actually writing to c:\windows\pwned.file which is a location only writable by an administrator account. That is in fact possible as the NVIDIA service is running as NT AUTHORITY\SYSTEM. Unfortunately, at first glance, inspecting the content of the log file seemed that I was not able to control any part of it, rendering this vulnerability pretty much useless as I was not able to do more than a Denial of Service (DoS) corrupting some system-level file.

Command Execution

I am not able to control the file's content, am I? Poking around with different GFE’s settings, I've discovered that toggling ON/OFF the GameStream/ShadowPlay button will cause the values present in C:\ProgramData\NVIDIA Corporation\NvStreamSrv\settings.txt file to be written in the nvstreamsvcCurrent log file. settings.txt contains the following lines and was writable by any user:

GswsDeviceUri=https://prod.gamestream.nvidia.com
GSProxyUri=https://proxy.gamestream.nvidia.com
StarFleetKeyValueDataStoreUri=https://userstore.nvidia.com

Appending some “pattern” values to the above variables and toggling the following button I was able to confirm logs pollution capabilities. GswsDeviceUri & StarFleetKeyValueDataStoreUri parameters where in fact copied from the settings.txt file and appended into nvstreamsvcCurrent.log file. Given the fact that I was able to write something arbitrary, anywhere on the file system, it was enough to write a .bat file to the system startup folder and have the injected commands executed in the context of the user that logs in.

Elevation of Privileges (EoP)

However, I wanted to achieve the highest impact on the system form a low privileged user perspective, so I dived further. NVIDIA has a batch file that can be found in C:\Windows\NvContainerRecovery.bat; this file is executed as SYSTEM whenever the "Nvidia Display Container" service crash more than 2 times. This is part of the default recovery settings for the NVIDIA services as can be shown below: That was the missing piece of the puzzle that allowed me to achieve a full privilege escalation code execution.

Exploit Recap

1. Using the NTFS rename operation to move the content of C:\ProgramData\NVIDIA Corporation\ into another writable location.
2. Setting up the symlink from C:\ProgramData\NVIDIA Corporation\nvstreamsvc\nvstreamsvcCurrent.log to C:\Windows\NvContainerRecovery.bat.
3. Append any command (exploit code) to the GswsDeviceUri or StarFleetKeyValueDataStoreUri settings in C:\ProgramData\NVIDIA Corporation\NvStreamSrv\settings.txt.
4. Triggering the Arbitrary File Write vulnerability toggling ON/OFF the GameStream/ShadowPlay
5. Above action will copy the content of C:\ProgramData\NVIDIA Corporation\NvStreamSrv\settings.txt to the newly created symlink, writing the content to C:\Windows\NvContainerRecovery.bat.
6. Crashing the NvContainerLocalSystem service three times triggering the Command Execution stored in bat in the context of NT AUTHORITY\SYSTEM (Elevation of Privilege).

Disclosure Timeline

• March 03, 2021 – Issue reported to NVIDIA, PSIRT case opened
• April 12, 2021 – Issue confirmed by NVIDIA to be fixed in GFE 3.22
• April 12, 2021 – Issue patched in GFE 3.22
• April 19, 2021 – Advisory posted by NVIDIA, assigned it to CVE-2021-1079

Resources & References

• Intro to privileged file operation abuse
• Symbolic Link Testing Tool
• From directory deletion to SYSTEM shell
• LocalSystem Account

Author

Paolo Stagno (aka VoidSec) is a Vulnerability Researcher and Exploit Developer focused on Windows offensive application security (kernel and user-land). He enjoys understanding the digital world we live in, disassembling, reverse engineering and exploiting complex products and code.