Steam Windows Client Local Privilege Escalation 0day
Introduction
I have been searching for vulnerabilities for a number of years and I thought I have seen a lot, but there is a part of work that I cannot understand and cannot accept. This is the absolute vendors’ unwillingness to accept information about vulnerabilities and problems. I understand that it is very unpleasant when someone directly shows you that you made a mistake and, most likely, not one. It is difficult to confirm in public sources that there were problems, that the staff did something wrong. However, I don’t understand why a vulnerability report rejected.
Well, I want to talk about Steam by Valve Software.
Vulnerability
The vulnerability itself is very simple. Steam installs “Steam Client Service” service for some internal purposes. Let’s check SDDL (https://habr.com/ru/company/pm/blog/442662/) of the service:
O:SYG:SYD:(A;;CCLCSWLOCRRC;;;IU)(A;;CCLCSWLOCRRC;;;SU)(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;RPWP;;;BU)
Most interesting part is (A;;RPWP;;;BU). It means that any user from the group “Users” is permitted to Start and Stop the service.
Now we examine the service's behavior at start. There is nearly nothing interesting in fact, but some registry operations look strange. Service enumerates subkeys of HKLM\Software\Wow6432Node\Valve\Steam\Apps and sets some security descriptions for each.
What is this security description about? 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.
Steam’s service sets security descriptor for our target-key. Review SDDL for the key (non-interesting data is omitted):
(A;ID;KA;;;BU)(A;OICIIOID;GA;;;BU)
In other words, it means full (read and write) access to the key for all users. This is the security descriptor the service has set to the key.
So, now we have a primitive to take control on almost every key in the registry, and it is easy to convert it into a complete EoP (Escalation of Privileges). I choose key HKLM\SYSTEM\ControlSet001\Services\msiserver that corresponds with the service “Windows Installer”, which can be started by any user, same as Steam’s service, but run program as NT AUTHORITY\SYSTEM. After taking control, it is only necessary to change ImagePath value of the HKLM\SYSTEM\ControlSet001\Services\msiserver key and start “Windows Installer” service. The program from ImagePath will be started as NT AUTHORITY\SYSTEM.
Put all things together and we get exploit that allows running any program with the highest possible rights on any Windows computer with Steam installed.
Report to vendor
I reported this vulnerability to the Valve via HackerOne.
Here first unexpected obstacle happened – before Valve I had to pass HackerOne’s staff review (because Valve use «Managed by HackerOne» feature on H1). I thought it is easy. How something could went wrong, if I provided a text description and a PoC as an executable file, which spawned an interactive command line console as NT AUTHORITY\SYSTEM? Therefore, I got “not applicable” with cause «Attacks that require the ability to drop files in arbitrary locations on the user's filesystem». I was like “Are you serious? There is no even a single file operation!”.
I wrote some comments and other H1 member tried to reproduce my steps. After some conversations, he confirmed the report and sent it to the Valve security team. Hooray! Mission accomplished. Or not…?
Some weeks later, another (third) H1 member marked report as “N\A”. Now there were two causes: «Attacks that require the ability to drop files in arbitrary locations on the user's filesystem» and «Attacks that require physical access to the user’s device». Here I realized that Valve has no interest in EoP vulnerabilities.
45 days have gone since the initial report, so I want to publicly disclose the vulnerability. I hope this will bring Steam developers to make some security improvements.
Some stats: vulnerability checked on Windows 8 x64, Windows 8.1 x64 и Windows 10 x64. I do not know how Steam works with version numbers of components, so I just write down versions of files:
-
SteamService.dll (5.16.86.11, signed by Valve 14.06.2019)
-
SteamService.exe (5.16.86.11, signed by Valve 14.06.2019)
Timeline
June 15 — reported via HackeOne.
June 16 — marked as “N\A”, due to "Attacks that require the ability to drop files in arbitrary locations on the user's filesystem».
June 16 — reopened with my comments.
July 2 — vulnerability confirmed by HackerOne staff and submitted it to the appropriate remediation team for review.
July 20 — marked as “N\A”, "Attacks that require the ability to drop files in arbitrary locations on the user's filesystem." and "Attacks that require physical access to the user’s device".
August 7 — public disclosure (this paper).
Some speculations
I am very disappointed. Big serious company speaks pathos words about security importance and, at the same time, makes your computer defenseless. In fact, Steam allows to grant high privileges for every program you run.
It is rather ironic that a launcher, which is actually designed to run third-party programs on your computer, allows them to silently get a maximum of privileges. Are you sure that a free game made of garbage by an unknown developer will behave honestly? Do you believe that for a 90% discount you will not get a hidden miner? Of course, some of the threats will remain even being run without administrator rights. However, the high rights of malicious programs can significantly increase risks - programs could disable antivirus, use deep and dark places to hide and change almost any file of any user, even stole private data.
Due to the popularity of Steam, there is a big amount of potential victims. In 2015, Valve reported that there were 125 million active accounts on Steam. Yes, not all Steam users have Windows as OS, but most of them do. Some users have multiple "live" accounts on single machine, however, the scale of the problem is still impressive.
Oh... What if there is no coincidence and the behavior is insecure by design? What if the Steam is a kind of legal backdoor? It is impossible to convict Valve, but putting all the facts together:
1) There is the vulnerability, which is easy to exploit and reliable works, providing high rights. And it seems like not only one, according to this twitter thread https://twitter.com/enigma0x3/status/1148031014171811841.
2) It is easy to find the vulnerability. I am not sure that I'm first who has found it, but the first one who wrote about it.
3) Valve declined the report about the EoP vulnerability and same ones. Moreover, the scope of incoming reports specially reduced to exclude EoP-reports.
As for me, it looks like Valve wants these EoP vulnerabilities to be present in the software.
It does not look good. I do not recall deleting Steam, but you should be aware and careful with it. Valve do not care about your security, so you are the only one who should be.
Bonus
The thing is that it was decided to expand the timeline because of a quite interesting event which occurred during the preparation of this article:
July 20 — after the report was rejected, I informed H1, that I would disclose the details of vulnerability publicly after July 30.
August 2 — one more H1 employee appears in the thread and forbids the disclosure.
This article was ready for publication by July 30 (this date was chosen due to 45 days deadline since initial vulnerability report was sent). So, two weeks after my message, which was sent on July 20, a person appears, who tells me that my report was marked as not applicable, they closed the discussion and wouldn’t offer any explanation to me. Moreover, they didn't want me to disclose the vulnerability. At the same time, there was not even a single word from Valve. No, guys, that's not how it works. You didn’t respect my work, and that's the reason why I won’t respect yours — I see no reason why I shouldn't publish this report. Most likely I’ll be banned at H1 because of it, but it won't make me upset.
UPD
Yesterday (August 6, 2019) Steam was updated. No, problem is not fixed. File versions: 5.27.59.20 signed at 06 Aug 2019.
UPD 2
Aug 7 (after the post) – H1 report was reopened. I got long mail from h1 community team. In short: I need provide more arguments on the vulnerability's importance. Also, there was a line: "Valve is not going to fix something that they have determined to be N/A". After that I realize, that public disclosure was a right desicion.
Aug 7 – Matt Nelson states that his vulnerability is the same as mine. And posts his PoC.
Aug 9 – Steam Beta got update with "Fixed privilege escalation exploit using symbolic links in Windows registry". It seems this fix could be bypassed. Where is my popcorn?
Aug 13 - Steam (main client, not beta) got update with "Fixed privilege escalation exploit using symbolic links in Windows registry". It seems, that there aren't any RegSetKeySecurity calls. Probably fixed.
Aug 15 - researcher provides a way to bypass latest patch https://twitter.com/general_nfs/status/1162067274443833344. So, the vulnerability is still actual.
About author
Vasily Kravets, Lead Expert
