Valve Says Turning Away Researcher Reporting Steam Vulnerability Was a Mistake (arstechnica.com) 27
An anonymous reader quotes a report from Ars Technica: In an attempt to quell a controversy that has raised the ire of white-hat hackers, the maker of the Steam online game platform said on Thursday it made a mistake when it turned away a researcher who recently reported two separate vulnerabilities. In its statement, Valve Corporation references HackerOne, the reporting service that helps thousands of companies receive and respond to vulnerabilities in their software or hardware. Valve's new HackerOne program rules specifically provide that "any case that allows malware or compromised software to perform a privilege escalation through Steam, without providing administrative credentials or confirming a UAC dialog, is in scope. Any unauthorized modification of the privileged Steam Client Service is also in scope."
The statement and the policy change from Valve came two days after security researcher Vasily Kravets, an independent researcher from Moscow, received an email telling him that Valve's security team would no longer receive his vulnerability reports through the HackerOne bug-reporting service. Valve turned Kravets away after he reported a steam vulnerability that allowed hackers who already had a toe-hold on a vulnerable computer to burrow into privileged parts of an operating system. Valve initially told Kravets such vulnerabilities were out of scope and gave no indication that the one Vasily reported would be fixed. The company later publicly denied that the issue was a vulnerability by incorrectly claiming that the exploit required hackers to have physical access to a vulnerable computer. The company went so far as to dispute the vulnerability in the advisory issued by the National Institute of Standards and Technology.
The statement and the policy change from Valve came two days after security researcher Vasily Kravets, an independent researcher from Moscow, received an email telling him that Valve's security team would no longer receive his vulnerability reports through the HackerOne bug-reporting service. Valve turned Kravets away after he reported a steam vulnerability that allowed hackers who already had a toe-hold on a vulnerable computer to burrow into privileged parts of an operating system. Valve initially told Kravets such vulnerabilities were out of scope and gave no indication that the one Vasily reported would be fixed. The company later publicly denied that the issue was a vulnerability by incorrectly claiming that the exploit required hackers to have physical access to a vulnerable computer. The company went so far as to dispute the vulnerability in the advisory issued by the National Institute of Standards and Technology.
Weird (Score:3, Insightful)
Re:Weird (Score:5, Insightful)
I don't know why, but some people see security bug reports as annoyances and would rather have them out of sight, out of mind.
Long, long ago I was a programmer for the free MMORPG Eternal Lands. I noticed that there was a terrible amount of "just trust it because it comes from the right IP" going on on the client code (I had no access to the server code, but I imagine it was just as bad). They had no interest whatsoever in adding any sort of authentication - trusting TCP was good enough for them. Okay, whatever. But I was greatly concerned when I saw their method for launching a web browser. When a person says a URL, it turns into a link, and if you click that, that starts up a web browser. Via popen. By just copying the user-provided URL text into the command line string.
Right about now, you should have giant red klaxons going off in your head, and if you don't, you're part of the problem.
It was an obvious injection attack vulnerability. I reported it. It was completely dismissed. I tried to stress how important it was to fix it, how dangerous this was. The reaction was just, "Nah, we don't want to touch that part of the code, it works fine and we don't want to break it." I literally had to go into the game and shout a URL that looked innocent but, if clicked, would generate a file in the user's home directory - in order to show that I could well have instead deleted the user's home directory, or pretty much anything I wanted. Only then did they finally accept, gee, injection attacks are serious and probably shouldn't be ignored...
They tried to go about fixing it in a dumb way, however, just blocking specific characters, and too few of them at that - even though I'd already given them a proper fix. They never did let me or anyone else add in authentication for the messaging system, however.
Re: (Score:3)
Your thing offered remote command injection. The worst of the bad class classes of vulnerabilities.
Valve's thing is an awful lot of fuss over a "local privilege escalation" class of vulnerability on a single-user computer. Let's face it, if you can execute arbitrary code on a Windows computer but can't find a path up to Administrator, you're not trying hard enough.
Re: (Score:2)
Re: (Score:2)
Hey now, don't be raging on the white hat for doing white hat things. Not all of us have the meme darkness in our souls.
Re: (Score:2)
They think it's easier to gain forgiveness than permission, but they are about to find out how wrong they are.
I believe you are wrong. The outrage would probably pass in a week. Most Steam users are too invested in Steam applications to just say "that's it, screw this".
Re: (Score:2)
You people are talking as if Valve is the managing partner of Hackerone. You're missing the fact that all these companies are depending on a single commercial service, Hackerone, to administer their security bug reporting management.
Hackerone is at least equal in blame as Valve, and I would argue moreso, because its apparent they're rubber stamping silencing of security researchers. Its not Valve that has locked out Kravets out of the security reporting system, its Hackerone!
Reinstate and pay them. (Score:4)
Great they admitted they were wrong. However, the part they failed to do is actually reinstate their ability to participate in the bounty program and pay them the bounties for the bugs already reported.
Seriously, it shouldn't be this difficult to get a company to actually do the right thing,
Great news. (Score:1)
Now maybe they can start addressing the numerous gaping holes in the user profile features.
The head should roll (Score:5, Interesting)
Re: (Score:1)
Sometimes bribe-able people.
Re: (Score:2)
Even the PR department should be given a slap on the back of the head, this entire incident would have been nothing more than a blip on the radar if they had handled it better.
PR doesn't manage policy. PR's job is to whitewash atrocities.of incompetent management. PR doesn't tell management to take security exploits more seriously, or shut out the messenger.
I'm going to need to see some action (Score:2)
It's quite cheap to make a statement of policy change, but how do I know it's real? How do I know it will be maintained, or not just changed back when my attention is elsewhere?
I'm going to need to see some substantive action before I'll consider this as anything more than a PR move.
Just like the Epstein Escape/Suicide, mistakes we (Score:2)
Re: (Score:2)
Well, to be truthful, it doesn't get privileges on my system. I tried to install it a couple of times, but never succeeded. If it want's analogous privileges on Linux, that may be why. (But I honestly think it had more to do with 32bit vs. 64bit incompatibilities.)
Re: Just like the Epstein Escape/Suicide, mistakes (Score:4, Insightful)
I spent the better part of 2 hours trying to get steam client to properly obey a set ACLs that would have mitigated the newest vuln yesterday, by preventing rename or deletion of the ./bin folder. (On windows.) If the folder has contents, you cannot use it as a repartee point, and if you cannot delete it, rename it, or its content, you cannot perfom the attack. But--
Valve detects that it is not writable and causes a hissy fit. So I tried giving modify and append privs... then the client erroneously thinks it needs to update, and fails, because replacing files needs delete priv.
The current client just is not written in a way that even considers respecting account access restrictions. (And instead makes some very dumb desicions to determine it needs to update.) Someone very important in the development team does not grok limited user, or actively is trying to always be system for dumb reasons instead of being compliant with security practices, like user access restrictions.
You would think they would trap a "user doesnt have write permission" event, then call UAC like good programmers, so the user can respond to the access request. But no. Not Valve. They throw up a custom dialogue box asserting the install location is not writable, and offer a button to helpfully grant that access instead.
The only folder limited user should have full control over in there is the content folder where steam installs games. There's maybe a legit reason for that. Anything with a system service should be read only to limited users. Burying your head in the sand to evade such restrictions, out of a wanton desire to not have to deal with security prompts on client updates, is bullshit.
Hell, since the client service is already system, it can just ignore limited user restrictions on updates, but I don't want to give the moron responsible for this bad ideas. (It's a bad idea because it gives a hook to call to escalate a calling process without user knowledge. Probably without challenge.)
The short version: windows steam client is fundamentally broken in regard to its security model, and complains if you try to bring it under control. I suspect that is the REAL reason for rejecting these reports.
Re: (Score:2)
Thank you for describing. I realize file ACLs don't have to be part of a separate kernel thing like SELinux, but the difficulties with a third-party program and restricted access sound like a lot of admins' experiences with selinux. Please keep up your efforts! If you ever solve it, maybe you can share how you did it. I don't know if file ACLs can be transcribed and made portable like an selinux policy, but that would be nice.
The downside of an selinux policy, is that the files have to be assigned the conte
Re: (Score:2)
When the first vuln came out, I mitigated it with a registry ACL that restricts rename, delete, and create symlink. Steam client played nice with that.
But this recent one involves pulling a bait and switch with a DLL registered with a system daemon, that the user is able to mess with (and replace with a malicious version).
To fix it, you have to prevent that DLL from being replaced. Changing the registry path for the service DLL should have been fixed by the prior vuln being closed. (Should.). This latest
Re: (Score:2)
Somebody doesn't understand security. (Score:2)
What I get from this is that they realize that zero-days are annoying to them, as is universal condemnation from the security community. It's "bad press".
What I don't get from this is that anything fundamental has changed. In fact, it suggests that their corporate culture is one that might well result in wide-ranging security problems.
Silly hackers (Score:2)
Re: (Score:2)
They won't. They'll just cash in with the NSA, MSS, or whatever program the Russians run.
How to respond to users (Score:2)
2. Respond to the user thanking them and letting them know when the problem will be looked at.
3. As more information is gathered/if more support is needed tell the user.
4. Tell the user when the problem will be fixed.
5. Fix the problem.
6. Thank the user again for their work.
7. Ask the user how they want the result reported to the world. Thank them again.
8. Wait for the next email.
The user doing the reporting is happy. They might do more reporting for f
HR for bug reporting? (Score:3)
So if I understood the article correctly, Valve outsources bug reporting to a separate company called HackerOne? Who then used a poorly implemented checklist-style logic to define it as "Out of scope" and sent form letters warning people not to disclose the bugs?
This sounds a lot like commercial HR contracting, and I imagine it will work almost as well in providing quality bug reporting as HR staffing companies do at providing quality employees.