Shulou(Shulou.com)05/31 Report--

NVIDIA arbitrary file writing command execution analysis, I believe that many inexperienced people do not know what to do, so this paper summarizes the causes of the problem and solutions, through this article I hope you can solve this problem.

Introduction of loopholes

In this article, we will delve into the arbitrary file write vulnerability (CVE-2019-5674) in NVIDIA GeForce Experience (GFE). As we all know, many devices that use N cards install NVIDIA GeForce Experience (GFE) by default when installing NVIDIA GeForce products. Due to this vulnerability, attackers will be able to force applications to write arbitrary files on the target system as privileged users. To put it simply, you can rewrite critical system files to disable the host, and you can even control, use, and steal data from the target system.

Because GFE uses SYSTEM user rights when writing to log files, this unsafe permission setting will cause any system file to be overwritten. In addition, the data in the log file is also user-controllable, and attackers will be able to inject control commands into the log file and then store it as a batch file to execute and lift rights.

NVIDIA GeForce Experience

According to NVIDIA's website, GeForce Experience GFE can not only update and upgrade video drivers and optimize your game settings, but also take screenshots or share video streams with friends. More importantly, it can provide more additional functions for N card users.

Loophole discovery

At that time, when I was analyzing NVIDIA services and applications, I first opened the process monitoring software (Procmon), and after the analysis, I found that there were two NVIDIA-related processes that might be interesting: nvcontainer.exe and NVDisplay.Container.exe. Next, I added a filter to Procmon to see that * container.exe writes data to those files.

With the help of the filter, we only need to pay attention to the "write file" operation, as you can see in the following figure, these processes will use "NT AUTHORITY\ SYSTEM" to write multiple log files to the "C:\ ProgramData" directory (including files that can be modified by ordinary users).

After checking the permissions of these files, we can see that the users in the "Everyone" group have full control over these files.

Therefore, members of both the SYSTEM group and the Everyone group are free to control these files, including creating hard links or symbolic links to other system files. If an attacker cannot modify a system file as a normal user, after creating a link associated with the file, the SYSTEM process searches for the link (itself a log file, which is writable by default) and allows data to be written to the file. The affected files will include critical system files that, if illegally modified, will cause the application or operating system to crash.

Exploit arbitrary file writing vulnerabilities

Before exploiting this vulnerability, we need to use symboliclink-testing-tools to create symbolic links and hard links, because this tool can help us create links to system files with normal user privileges. During the test, I also used the Createsymlink tool and created a temporary symbolic link: "C:\ ProgramData\ NVIDIACorporation\ nvstapisvr\ nvstapisvr.log" = > "C:\ windows\ test.file". This test.file file can only be written by an administrator. To ensure that the symbolic link is created successfully, we need to leave the "C:\ ProgramData\ NVIDIACorporation\ nvstapisvr\" directory empty, and if it is not empty, you will see the error message shown in the following figure:

Next, when the NVIDIA privileged process writes data to the log file "C:\ ProgramData\ NVIDIACorporation\ nvstapisvr\ nvstapisvr.log", it is actually writing data to "C:\ windows\ test.file".

This shows that this vulnerability may allow us to rewrite arbitrary system files. But that's not enough, because we can't crash some files or deny the system service. This is because the data in a particular log file is still uncontrollable, and it only writes all the log data that should have been recorded.

Therefore, we need to control the data written to the log file. After analysis, I found that "C:\ ProgramData\ NVIDIACorporation\ nvstreamsvc\ nvstreamsvcCurrent.log" contains some interesting strings, and when the "GameStream" switch of GeForce Experience is turned on or off, some variables contained in "C:\ ProgramData\ NVIDIACorporation\ NvStreamSrv\ settings.txt" are written to the nvstreamsvcCurren log file.

Click this switch to allow "C:\ ProgramData\ NVIDIACorporation\ nvstreamsvc\ nvstreamsvcCurrent.log" to record the URL address contained in the settings.txt file:

Next, I try to add some commands to the values of these variables to modify the log file:

Sure enough, it worked:

Although there is a pile of other log data here, the commands we injected will eventually be executed in the .bat file. In addition, now that I can write files to any directory, I can inject valid commands into the flawed files, then write the files to the system boot directory, and then execute the injected commands to finally lift the rights.

But there is still a problem, that is, the directory where the symbolic link was created must be empty, but now the directory contains the files needed by the NVIDIA service, and I can't delete it. However, the problem is solved when it goes into safe mode.

To sum up:

1. Add the commands you need to execute to "C:\ ProgramData\ NVIDIACorporation\ NvStreamSrv\ settings.txt"

2. Clear the "C:\ ProgramData\ NVIDIACorporation\ nvstreamsvc\" directory

3. Create a symbolic link: "C:\ ProgramData\ NVIDIACorporation\ nvstreamsvc\ nvstreamsvcCurrent.log" = > "C:\ ProgramData\ Microsoft\ Windows\ Start Menu\ Programs\ StartUp\ cmd.bat"

Create a symbolic link:

Toggle the switch for the "GameStream" service, and then our cmd.bat file will be in the system boot directory:

Complete lifting of rights

NVIDIA itself comes with many batch files, which can be found in the "C:\ Windows" directory:

When the "NVIDIA Display Container" or "NVIDIA TelemetryContainer" service crashes more than twice, these files run with SYSTEM privileges, which is the recovery mechanism of the NVIDIA service:

These files are also available to us, and we only need to crash the NVIDIA service three times to force the BAT file to execute and elevate the rights.

Affected version GeForce Experience

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.