The popular Steam game client for Windows has a zero-day privilege escalation vulnerability that can allow an attacker with limited permissions to run a program as an administrator

Privilege escalation vulnerabilities are bugs that enable a user with limited rights to launch an executable with elevated, or administrative privileges. With Steam having over 100 million registered users and millions of them playing at a time, this is a serious risk that could be abused by malware to perform a variety of unwanted activities.

The privilege escalation vulnerability

Two researchers publicly disclosed a zero-day vulnerability for the Steam client after Valve determined that the flaw was "Not Applicable." When the vulnerability was submitted to Valve's bug bounty program on HackerOne, the company chose not award a bug bounty or give an indication that they would fix it, and told the researchers that they were not allowed to disclose it.

In a report published yesterday, security researcher Felix was analyzing a Windows service associated with the Steam client called "Steam Client Service". When started, this service launched its executable with SYSTEM privileges on Windows. The researcher also noticed that the service could be started and stopped by the "User" group, which is pretty much anyone logged on the computer.

The registry key for this service, though, was not writable by the "User" group, so it could not be modified to launch a different executable and elevate its privileges to an administrator.

The researcher did find something strange, though. When the service was started and stopped, it gave the "Users" group full write access to the subkeys under the HKLM\Software\Wow6432Node\Valve\Steam\Apps Registry key.

"I created test key HKLM\Software\Wow6432Node\Valve\Steam\Apps\test and restarted the service (Procmon’s log is above) and checked registry key permissions. Here I found that HKLM\SOFTWARE\Wow6432Node\Valve\Steam has explicit “Full control” for “Users” group, and these permissions inherit for all subkeys and their subkeys. I assumed that RegSetKeySecurity sets same rights, and something interesting would happen if there were a symlink. I created a link from HKLM\SOFTWARE\Wow6432Node\Valve\Steam\Apps\test to HKLM\SOFTWARE\test2 and restarted the service."

The researcher then tried configuring a symlink from one of these subkeys to another key for which he did not have sufficient permissions. After restarting the service, he saw that it was now possible to modify that key as well.

With this knowledge in hand, the researcher realized that any Registry key could be modified by simply creating a symlink from a subkey under HKLM\Software\Wow6432Node\Valve\Steam\Apps to a secure Registry key and then restarting the service.

This could allow a service running with SYSTEM privileges to be modified so that it launched a different program with elevated rights.

Thus a privilege elevation vulnerability was born.

PoC disclosed by another researcher

After Felix disclosed the vulnerability in a write up, a second researcher named Matt Nelson, who is well known for discovering privilege escalation vulnerabilities under the enigma0x3 alias, shared a proof-of-concept (PoC) script on GitHub that abuses the flaw.

Nelson's PoC creates a symlink back to the HKLM:\SYSTEM\CurrentControlSet\Services\Steam Client Service so that it could change the executable that is launched when the service is restarted.

If the PoC is successful, a Windows command prompt with Administrative privileges will be launched in the background, as shown below.

Command Prompt with Elevated Privileges

Nelson says that he too had disclosure issues with Valve.

A source familiar with the matter has stated that HackerOne has reopened the bug report to further investigate it.

BleepingComputer has contacted Valve for more questions on why the vulnerability was not fixed, but had not heard back at the time of this publication.