A second Steam Windows client zero-day privilege escalation vulnerability affecting over 96 million users has been publicly disclosed today by Russian researcher Vasily Kravets.
This happens after Valve disputed the significance of the previous Steam 0day disclosed by Kravets on Twitter and banned him out of their HackerOne bug bounty program.
Seeing that this vulnerability impacts only the Steam Windows client, with Steam having over 100 million registered users and 96.28% of them are running Windows according to the Steam Hardware & Software Survey: July 2019, the systems of roughly 96 millions of them are currently affected.
The privilege escalation (also known as an elevation of privilege or local privilege escalation) security flaw disclosed today by Kravets can allow attackers with limited rights to use a technique known as BaitAndSwitch to run executables using the Steam Client Service's NT AUTHORITY\SYSTEM elevated permissions.
This would allow potential attackers to launch a three-stage attack, getting remote code execution privileges by exploiting a vulnerability in a Steam game, a Windows app, or the OS itself, subsequently elevating privileges on the compromised device and running a malicious payload using SYSTEM permissions.
As Kravets detailed in his write-up, "achieving maximum privileges can lead to much more disastrous consequences. For example, disabling firewall and antivirus, rootkit installation, concealing of process-miner, theft any PC user’s private data — is just a small portion of what could be done."
Valve banned me on their H1 program.
— Felix aka [xi-tauw] (@PsiDragon) August 20, 2019
So...
I release new #ZeroDay #PublicDisclosure EoP vulnerability at Steam.
Another #0day.
Rus - https://t.co/jAoq5kCTfF
Eng - https://t.co/FfGXltXmpX
The Steam security saga
Security researchers Vasily Kravets and Matt Nelson disclosed the previous zero-day vulnerability in Steam on August 7 that could enable local attackers or malware to run code on the system with elevated privileges.
The two researchers decided to disclose [1, 2] how to exploit the flaw after Valve declined to patch it saying that it was outside the scope of their HackerOne bug bounty program.
Valve disputed the privilege escalation flaw even after it got assigned the CVE-2019-14743 identifier, reportedly telling Kravets that "the Steam threat model excludes 'Attacks that require physical access to the user's device' and 'Attacks that require the ability to drop files in arbitrary locations on the user's filesystem'."
Following massive uproar from both Steam users and security researchers, Valve eventually decided to fix the vulnerability. However, researchers considered the fix to be incomplete, a fact that got confirmation after researcher Xiaoyin Liu disclosed a bypass to Valve's fix that allows attackers to exploit the flaw again.
I found a way to bypass the fix. The bypass requires dropping a file in a nonadmin-writable location, so I think it's out-of-scope for Valve. Write-up: https://t.co/Lalum8LTvY cc @PsiDragon @enigma0x3 @steam_games #infosec #steam #bugbounty https://t.co/qIylEG7u2L
— Xiaoyin Liu (@general_nfs) August 15, 2019
Kravets created the following two video demos for his second Steam privilege escalation vulnerability, showcasing the two exploitation methods attackers could use to gain SYSTEM permissions on any Windows system running an unpatched Steam version.
BleepingComputer has reached out to Valve for comment but had not heard back at the time of this publication. This article will be updated when a response is received.
We also contacted Valve for comments regarding the previously disclosed zero-day and the fix bypass found by Xiaoyin Liu but we got no reply so far.
Update August 22, 14:18 EDT: Valve's director of marketing Doug Lombardi sent the following official statement:
We are aware of the recent reports of two zero day local privilege escalation bugs related to the Steam Client. Both of these bugs used Steam to allow already installed malware to escalate from local user to administrator level privileges. Neither of these bugs could be executed remotely without first compromising a user’s machine outside of Steam. We have released updates to the Steam Client public beta channel to address these issues, and we have already pushed some initial fixes to all users.
We are also aware that the researcher who discovered the bugs was incorrectly turned away through our HackerOne bug bounty program, where his report was classified as out of scope. This was a mistake.
Our HackerOne program rules were intended only to exclude reports of Steam being instructed to launch previously installed malware on a user’s machine as that local user. Instead, misinterpretation of the rules also led to the exclusion of a more serious attack that also performed local privilege escalation through Steam.
We have updated our HackerOne program rules to explicitly state that these issues are in scope and should be reported. In the past two years, we have collaborated with and rewarded 263 security researchers in the community helping us identify and correct roughly 500 security issues, paying out over $675,000 in bounties. We look forward to continuing to work with the security community to improve the security of our products through the HackerOne program.
In regards to the specific researchers, we are reviewing the details of each situation to determine the appropriate actions. We aren’t going to discuss the details of each situation or the status of their accounts at this time.
Comments
fromFirefoxToVivaldi - 4 years ago
There are vulnerabilities that date back to 2015 still unpatched, like this one https://nvd.nist.gov/vuln/detail/CVE-2015-7985, which was recently mentioned on a security blog from my country, although admittedly it has a low exploitability as the user is required to for some reason start Steam.exe as admin for the attacker to gain anything.
Allen - 4 years ago
"This would allow potential attackers to launch a three-stage attack, getting remote code execution privileges by exploiting a vulnerability in a Steam game, a Windows app, or the OS itself, subsequently elevating privileges on the compromised device and running a malicious payload using SYSTEM permissions."
I actually tweeted something similar to this about 5 hours before this article came out (https://twitter.com/FMC0RE/status/1164167330823380993) glad to see that I wasn't the only one who thought of how easily this exploit could be used through RCE.
chilinux - 4 years ago
It is interesting that no matter how many times BleepingComputer publishes articles that this service contains a verifiable vulnerability with this service, the BleepingComputer Startup Programs Database still lists it as valid:
https://www.bleepingcomputer.com/startups/SteamService.exe-20541.html
The database has a five different statuses a database entry can have but none of those statuses really apply to Vulnerable/Known Issues. Maybe the entry to should get an X status flag for "item should definitely not start up automatically" until an additional status can be added. The service is literally designed to be a bypass to the UAC security model of Windows!
GT500 - 4 years ago
Of course it's valid. It's a legitimate program from a legitimate software publisher. Just because it has a few vulnerabilities here and there doesn't mean that it suddenly isn't valid or legitimate. If that were the case then Google Chrome, Firefox, and most other popular softwares would need to have their classifications changed as well.
chilinux - 4 years ago
I'm sorry GT500 but can you please remind me of the security vulnerability report for any version of Chrome or Firefox that allowed an unprivileged user to obtain full system user level access? I can not find one.
The excuse of "it's a legitimate program from a legitimate software publisher" was also used for a long time to defend the Sony XCP rootkit. At this point there should be an established policy that what makes a program legitimate or a security risk is the behavior of the application instead of how big a brand and company is publishing it.
Consider this for comparison, Zoom Video Communications application became established enough to be able to list Nasdaq, UBER, SONOS and Logitech as customers. They made to it 4 million users. But when it became clear the software made easy for an attacker to view the webcam without warning, Apple blacklisted the vulnerable software.
The privilege escalation bug that Valve authored is installed on over 80 million Windows systems. This bug allows an attacker to do much greater damage than just view the webcam (which having system level access also permits doing). Isn't it possible that maybe this service is at least deserving of a *warning* status at this point?
Allen - 4 years ago
Well actually this is a windows caused bug, that VALVe just makes easy to exploit by not locking down their folder permissions.
GT500 - 4 years ago
What about this one?
https://www.mozilla.org/en-US/security/advisories/mfsa2009-51/
GT500 - 4 years ago
I'm actually finding quite a few of these, but I'll only post one more just to prove that Google Chome has had reports of them as well:
https://www.cvedetails.com/cve/CVE-2019-5809/
And if we want to talk about privilege escalation vulnerabilities in software installed on 80+ million computers, then what about all of the privilege escalation vulnerabilities that have been found in Microsoft software (such as various components of Windows)?
The extreme reaction to Steam having a couple of LPE vulnerabilities is not only not warranted, it's ludicrous. The only real problem here is the fact that they mishandled the vulnerability reports, however after the latest news hopefully that will change and we'll all get a safer and more secure Steam client.
chilinux - 4 years ago
mfsa2009-51 allows escaping the javascript sandbox to in-browser "chrome" level permission.
CVE-2019-5809 appears to also be escalation from the renderer to a higher in-browser access.
Both of these are serious given the amount of confidential information we entrust our web browsers with and I'm glad the issues have been fixed, but neither of these meet the criteria I requested. None of these browser issues will allow an attacker to install a persistent rootkit using the operating system's most powerful system level user privileges because they do provide access to that.
So, I will try stating my request again with more emphasis on the part you missed:
"can you please remind me of the security vulnerability report for any version of Chrome or Firefox that allowed an unprivileged user to OBTAIN FULL SYSTEM USER LEVEL ACCESS?"
You can see the difference based on that criteria in the CVSS scoring between the Chrome bug you found and the bug Valve released. Chrome's LPE to in-browser level escalation has a CVSSv2 impact score of 6.4 with *partial* compromises in the areas of confidentiality, integrity and availability. Steam's vulnerability had a CVSSv2 impact score of 10 out of 10 with a *COMPLETE* compromise in the areas of confidentiality, integrity and availability.
But even with a LPE vulnerability that goes as bad as being an full UAC bypass that gives up access to the SYSTEM user account, that wouldn't justify the the level of extreme reaction.
Until ... they stated it was out of scope. (Which even they acknowledge now was a mistake).
And then down played "local" vulnerability to mean physical. The Steam service does allow playing games in offline mode but requires being on the network to install, update and launch the game for the first time. For a network connected computer, "local" exploit is *NOT* the same as physical. Their latest official statement implies it requires already installed malware. That also is not true, as Remote Code Execution vulnerabilities can leverage the Steam installed UAC bypass without being already installed malware. These misleading statements from Valve seem to indicate they are either incompetent at computer security or being willfully obtuse in their responses which puts a chilling effect on having a meaningful discussion.
They have a security philosophy web page that states:
"We recognize how important it is to help protect privacy and security. We understand that secure products and services are critical in establishing and maintaining trust with our users. We strive to consistently deliver secure and enjoyable experiences in all of our products and services."
How they responded to this issue was not even close to consistent with consistently delivering on security. By Valve's own criteria this situation was handled in a horrific way.
You want to also point out that Windows has had insecure components--that is completely true. It was disappointing to learn that Windows Defender, the component that is supposed to *improve* security had been itself a LPE. But they *acknowledged* the problem and they fixed it.
It is disappointing to learn the the Remote Desktop service also had extremely damning vulnerability (again!). But it was discovered *proactively* by an internal audit conducted by Microsoft's themselves and fixed. (Install the latest Windows Update if you have the Remote Desktop service running!)
Microsoft is able to achieve *proactive* results because it has a *team* of people dedicated to security. You can contact them on twitter via @msftsecurity
Valve has no equivalent. They outsourced security through the *reactionary* service of HackerOne (which we just learn does not really do a very professional job). When Steam Support is asked about escalating communications to a Valve security professional, they indicate it is not possible and point to the Valve people web page at:
https://www.valvesoftware.com/en/people
If you click through each of the people listed, you will find that there is no security team at Valve. There is not even a single person that indicates their full time job is computer security.
When a company worth around $3 billion dollars say they recognize the importance of privacy and security but can't indicate anyone at all being a member of their internal security team, that is worthy of an extreme reaction. In my opinion, that reaches the point of the Valve's published security philosophy being borderline fraud.