A Russian security researcher has published details about a zero-day in the Steam gaming client. This is the second Steam zero-day the researcher has made public in the past two weeks.
However, while the security researcher reported the first one to Valve and tried to have it fixed before public disclosure, he said he couldn’t do the same with the second because the company banned him from submitting further bug reports via its public bug bounty program on the HackerOne platform.
Valve gets criticized
The entire chain of events behind the public disclosure of these two zero-days has caused quite a drama and discussions in the infosec community.
All the negative comments have been aimed at Valve and the HackerOne staff, with both being acused of unprofessional behavior.
i am disappointed that valve does this kinda stuff https://t.co/z1JPKJmHhQ
— D̒͂̕ᵈăᵃn̕ᶰ Ť̾̾̓͐͒͠ᵗe͗̑́̋̂́͡ᵉn̅ᶰtᵗl̀̓͘ᶫe̓̒̂̚ᵉrʳ (@Viss) August 21, 2019
Security researchers and regular Steam users alike are mad because Valve refused to acknowledge the reported issue as a security flaw, and declined to patch it.
When the security researcher — named Vasily Kravets– wanted to publicly disclose the vulnerability, a HackerOne staff member forbade him from doing so, even if Valve had no intention of fixing the issue — effectively trying to prevent the researcher from letting users know there was a proble with the Steam client at all.
Kravets did eventually publish details about the Steam zero-day, which was an elevation of privilege (also known as a local privilege escalation) bug that allowed other apps or malware on a user’s computer to abuse the Steam client to run code with admin rights.
Kravets said he was banned from the platform following the public disclosure of the first zero-day. His bug report was heavily covered in the media, and Valve did eventually ship a fix, more as a reaction to all the bad press the company was getting.
The patch was almost immediatelly proved to be insufficient, and another security researcher found an easy way to go around it almost right away.
Valve bungled the same bug report twice
Furthermore, a well-known and highly respected security researcher named Matt Nelson also revealed he found the same exact bug, but after Kravets, which he too reported to Valve’s HackerOne program, only to go through a similar bad experience as Kravets.
Nelson said Valve and HackerOne took five days to acknowledge the bug, refused to patch it, and then locked the bug report when Nelson wanted to disclose the bug publicly and warn users.
Nelson later released proof-of-concept code for the first Steam zero-day, and also criticized Valve and HackerOne for their abysmall handling of his bug report.
The company at fault here is Valve (Steam). Good luck reporting anything that doesn’t fit their crappy bounty scope. https://t.co/vLHmTQ0qmq
— Matt Nelson (@enigma0x3) July 8, 2019
I’d like to take this Valve fiasco and highlight a few points:
1. Don’t scope your program so tightly that it completely removes things like LPE
2. If you do, give researchers a place to go that isn’t Twitter.
3. Don’t lock an issue when disclosure is mentioned pic.twitter.com/lygNLkiUiz— Matt Nelson (@enigma0x3) August 12, 2019
Second Steam zero-day disclosed today
Today, Kravets published details about a second Valve zero-day, which is another EoP/LPE in the Steam client, allowing malicious apps to gain admin rights through Valve’s Steam app. Demos of the second Steam zero-day are embedded below, and a technical write-up is available on Kravets’ site.
A Valve spokesperson did not reply to a request for comment, but the company rarely comments on security issues.
Problem: Valve doesn’t view EoP/LPE as security flaws
All of Valve’s problems seem to come from the fact that the company has placed EoP/LPE vulnerabilities as “out-of-scope” for its HackerOne platform, meaning the company doesn’t view them as security issues.
Nelson, a security researcher who has made a name for himself for finding a slew of interesting bugs in Microsoft products, doesn’t agree with Valve’s decision.
@steam_games that’s not really how that works. You can’t pick and choose what you define as a vulnerability. Your software is breaking the Windows security model.
— Matt Nelson (@enigma0x3) August 12, 2019
EoP/LPE vulnerabilities can’t allow a threat actor to hack a remote app or computer. They are vulnerabilities abused during post-exploitation, mostly so attackers can take full control over a target by gaining root/admin/system rights.
While Valve doesn’t consider these as security flaws, everyone else does. For example, Microsoft patches tens of EoP/LPE flaws each month, and OWASP considers EoP/LPE as the fifth most dangerous security flaw in its infamous Top 10 Vulnerabilities list.
By refusing to patch the first zero-day, Valve inadvertantly sent a message out that it doesn’t care about the security of its product, putting the company’s 100+ million Windows users in danger just by having the Steam client installed on their computers.
Sure! Valve is right, in its own way. An attacker can’t use an EoP/LPE to break into a Steam user’s client. That’s a fact. But, that’s not the point.
When users install the Steam client on their computers, they also don’t expect the app to be a launching pad for malware or other attacks.
An app and users’ security is more than remote code execution (RCE) bugs. Otherwise, if EoP/LPE bugs weren’t a big deal, everyone else wouldn’t bother patching them either.
More vulnerability reports:
Credit: Zdnet
