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.
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.
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.
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  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.