Steam Security Vulnerability Fixed, Researchers Don’t Agree

Steam

Valve has pushed out a fix for a zero-day Steam Client local privilege escalation (LPE) vulnerability, but researchers say there are still other LPE vulnerabilities that are being ignored.

Security researchers Matt Nelson and Vasily Kravets both recently discovered the same vulnerability in the widely used Steam Client software and were told that Valve would not be fixing it because it was “out of scope” of their vulnerability reporting program.

Nelson told the vulnerability would not be fixed
Nelson told the vulnerability would not be fixed

After the massive outcry generated by this decision, Valve has changed its mind and released a fix. Unfortunately, though, another similarly reported vulnerability still exists.

Valve’s local privilege escalation fix

The recently reported zero-day vulnerability was caused by the “Steam Client Service” Windows service giving the “USERS” group full permissions on any subkey under the HKLM\Software\Wow6432Node\Valve\Steam\Apps Registry key when the service was restarted.

With this knowledge in hand, the researchers figured out that they could create a link under this Registry key to another key that they did not have permission. When they restarted the Steam Client Service, the service would give that link full permission and thus also give the researchers permission to any other key in the Registry.

This could then allow them  to elevate the privileges of any program they wish on the computer, including malware.

To fix this, in the Steam Client Beta Valve made it so that the Steam service would  check the subkeys of the HKLM\Software\Wow6432Node\Valve\Steam\Apps Registry key using the RegQueryValueExA function as shown  below.

Check if subkey is a symbolic link
Check if subkey is a symbolic link

If the RegQueryValueExA function returned that the specific subkey was indeed a link, or REG_LINK, it would break out of the function and not give the “USER” group Full permission to the key.

Fix is not enough

While Valve may have fixed this one particular vulnerability in the “Steam Client Service”, researchers still say that there is a big gaping hole that was reported a long time ago and that can still be abused by attackers and malware to elevate their privileges.

Vulnerability researcher and 0Patch co-founder Mitja Kolsek told BleepingComputer that the “Steam Client Service” could still be used to elevate a user’s privileges through the DLL hijacking.

This vulnerability exists because the “USERS” group is given full permission to the Steam installation folder located at C:\Program Files (x86)\Steam. This means that an attacker can simply replace DLLs residing in that folder with a malicious copy that gives the attacker administrative access to the machine when it is launched by an elevated process or service.

USERS group has Full permissions
USERS group has Full permissions

This bug is not new either. 

Nelson told BleepingComputer that this issue has been present for a while, but has not been fixed. 

“Yeah, C:\Program Files (x86)\Steam being completely open is a terrible issue that has been present for quite some time. They do attempt to do some signature validation on those files, but I doubt its sufficient.”

In fact this issue was reported in 2015, given the CVE ID of  CVE-2015-7985, and to this day still has not been fixed.

“A privilege escalation vulnerability has been identified in that the Steam Microsoft Windows client software is installed with weak default permissions. These permissions grant read and write access to the Windows Users group for the install folder. This includes Steam.exe which is launched upon user login.”

Full permissions reportedly needed for self-update feature

These permissions are allegedly required [1] so that the Steam client software can self-update itself and other games.

When BleepingComputer asked Kolsek why Steam would need these permissions rather than just using an update procedure that requested elevated permissions, we were told:

“There is NO valid reason for a privileged service to have executable modules modifiable by normal users.”

BleepingComputer has reached out to Valve for comment as to why this vulnerability, and others like it, are not being fixed when reported to them through their bug bounty program.

We have not heard back at the time of this publication.