I mean, you can't have your cake and eat it too - if you claim that a particular issue is not a bug and you won't fix it, then you have no ethical grounds to say that it shouldn't be disclosed.
Responsible disclosure expects delaying public disclosure to protect the users while the vendor prepares a fix. If the vendor says that they won't fix it, then it's not only a right, but a moral duty to disclose that vulnerability to the users.
Frankly, I think HackerOne deserves a bit of blame for that. Any WONTFIX ought to be made public automatically unless there are extenuating circumstances (like the vulnerability being reported against the wrong product).
H1 itself has no WONTFIX status, FYI. A bug that's not considered to be a bug by the program will either be closed N/A or informative. Ultimately, disclosures are handled and controlled by the program, not by H1; this is both a good and bad thing (and I say that as both a HackerOne employee and a hacker on the platform -- it's a complicated issue from both sides).
HackerOne should be getting slated a lot more than they are.
They are selling their bug bounty program to their customers (e.g. Valve) as offering the equivalent control to a traditional pen test contract (with confidentiality) while also trying to sell the spec work/no findings, no pay price advantage of a bug bounty program. It's scummy as hell.
I uninstalled Steam the moment I read the previous disclosure and Valve's approach to it. Any company that treats security as it used to be in the 90s ought to be shunned.
You would think that any platform/app that actually contains the ability to load currency into itself would take any security threat seriously regardless of the scope.
The researcher can still disclose it, they just aren't going to get permission to disclose it on the Hackerone program. Most things out of scope don't get publicly disclosed as far as I know.
Without seeing the communications it's hard to say, but "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" sounds like more than just not being able to disclose on the H1 program.
> 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 immediately proved to be insufficient, and another security researcher found an easy way to go around it almost right away.
I see this as an example where the system works. Valve has an incentive to pay for bugs. The researcher than has an incentive to disclose them privately. If Valve doesn't pay fairly, the bug is disclosed, Valve pays the price and is forced to fix it, and be running a scam of a bug bounty program, they've exposed themselves to more disclosures. Valve now has an incentive to fix their program either by working with this bug hunter or increasing payouts so other hunters beat him to the point. This is how the system should work. Decentralized self-regulation needs people like Valve to fuck up once in a while so that the forces at play sufficiently punish them until they improve their process.
This story continues to be so sad. Steam is reprising the role of Adobe who, for quite a while, refused to acknowledge that being able to use FlashPlayer as a tool to get you something on Windows was just as bad as breaking FlashPlayer. I heard one Adobe executive say, "Hey you can use a baseball bat to bludgeon someone but that isn't the bat maker's fault is it? If they are forced to make foam bats their product is useless."
That position isn't "wrong" so much as it isn't useful in reducing risk.
No that position is wrong, because the analogy is wrong. If the baseball bat would hit the customer in the face every time he tries to hit the ball, that would get fixed pretty quick. Allowing privilege escalation is an unintended side effect of the product being used and should be fixed because the customer never asked to be exposed to that risk.
Knowledgeable people can just add Steam to the set of applications that must be installed in its own isolated environment. How would the typical Steam user know to do that? Is there a prominent warning on the install screen informing users that Steam will be used to hack their machine and anything they have stored on it?
How would one achieve this on Windows short of having the entire Windows install be isolated from your main OS? I would assume most users would not want to run their games in a VM inside Windows for performance reasons.
Could steam be legally liable for the issues bugs give to the end users if they know of the issud. I know they have TOS forbidding this but ToS need to take into account laws.
Well, that's the issue with DRMs. I never went into the Steam ecosystem because I don't like dependencies, but most people have no choice and have to use Steam if they want to access their game libraries.
With a foam bat. Just because the flash horse is dead doesn't mean it didn't deserve it's beating or can't continue to be a potent reminder of how bad Adobe was at handling security issues and why other platforms, like Steam, should learn instead of emulate.
Flash died because Adobe failed in the most obvious ways--even to lay outsiders at the time. They could never be bothered to fix the pervasive performance or security issues. It started to die, slowly at first: the desktop flash blocker plugins. Then very quickly: the lack of support from mobile OS--even though those companies practically begged Adobe to get its act together.
Adobe had a practical monopoly on the interactive web and blew it.
Maybe it is also time to switch from the prehistoric model of "hey let's download a .exe on the web, execute it without any sandbox, and let that .exe install other .exe from thousands of other unknown sources around the world and run them without any sandbox either."
Steam or any other app should always run sandboxed with no root access, no file access, no camera access, no access to other process, etc. For most users, steam only needs a sandboxed local storage to put its game into it and a internet access (and maybe mic access), that's it.
I really hope Flatpak and something similar for Window becomes the norm, the current situation is a security and privacy disaster.
There can still be exploits of course but now you have the find a weakness both in the app + in the OS sandbox which is a whole lot harder
> prehistoric model of "hey let's download a .exe on the web, execute it without any sandbox, and let that .exe install other .exe from thousands of other unknown sources around the world and run them without any sandbox either."
What year is it? To me prehistoric means buying a nice big box with a CDROM or some floppies and installing with no internet required at all. Shell exes that want to download crap is the current nightmare we are living in I thought.
Won't sandboxes impact performance of video games? I don't know much about sandboxes except that VMs are often used as sandboxes, and I definitely don't want video games running inside of VMs
Games typically need only access to video adapter, sound card and maybe network. They do not need access to your browser's cookies or history, or documents folder, for example. This probably doesn't require using VM.
The salient part seems to be that the researcher reported the first vulnerability through HackerOne and was (reportedly) told by Steam it wouldn’t be fixed. He then published it after being instructed that was against the rules and was banned
I wanted to note that the researcher was not banned at HackerOne, he was only banned from reporting bugs to Valve. This is written in the article about a second vulnerability [1]
I agree. As a user, I do not care who is at fault much, but I do expect the platform you provide to be somewhat secure.. especially after you are told it is not.
I basically uninstalled Steam client after first 0day was found. At least with gog I don't have install galaxy. But thats a different rant..
My opinion, not my (HackerOne customer) employer's:
I know this will be unpopular with folks like tptacek, but I've always felt strongly that bug bounty programs offer too many perverse incentives to all parties.
More often than not it becomes a tool for companies to sweep issues like this under the rug and then use HackerOne's system to force the reporters to play ball (because they want to keep getting paid). I hate this sytem.
I'm 100% behind open, public disclosure and if it were my own product in question, I would offer bounties for _public disclosures_. That keeps everyone honest.
I agree with you from the other side. Before these programs people would disclose issues to the public. The company found out like everyone else. They would fix it immediately because they had to.
Now they can hide it for months(ever) allowing others to discover them and keeping the researchers quiet.
- Researcher discloses bug publically once vendor has fixed, or after X time (whichever is first)
This is roughly how Project Zero goes, and it's a good mix between giving the vendor the opportinity to fix it and deploy the update before it gets exploited.
It's very naive to assume that bugs can be fixed before others can exploit them. Bugs take time to fix, and the process takes time, especially when dealing with large enterprises.
I seem to recall the HB site, in the early days, saying something to the effect of "Our promise: 100% DRM free games". They even did a bunch of bundles that donated part of the proceeds to the EFF. It's sad to see them as just another front for Steam sales.
Readit News
Responsible disclosure expects delaying public disclosure to protect the users while the vendor prepares a fix. If the vendor says that they won't fix it, then it's not only a right, but a moral duty to disclose that vulnerability to the users.
They are selling their bug bounty program to their customers (e.g. Valve) as offering the equivalent control to a traditional pen test contract (with confidentiality) while also trying to sell the spec work/no findings, no pay price advantage of a bug bounty program. It's scummy as hell.
Deleted Comment
Ended up naming it 'Bad QR', putting this page together and sending them a private link (https://writecodeeveryday.github.io/projects/badqr/)
Doesn't seem too unreasonable.
> The patch was almost immediately proved to be insufficient, and another security researcher found an easy way to go around it almost right away.
You might want to read the article.
That position isn't "wrong" so much as it isn't useful in reducing risk.
With a foam bat. Just because the flash horse is dead doesn't mean it didn't deserve it's beating or can't continue to be a potent reminder of how bad Adobe was at handling security issues and why other platforms, like Steam, should learn instead of emulate.
Adobe had a practical monopoly on the interactive web and blew it.
Those were the old days. Or, that damned monkey!
If no one will use or manufacture your baseball bat, then the danger of the bat is moot.
Steam or any other app should always run sandboxed with no root access, no file access, no camera access, no access to other process, etc. For most users, steam only needs a sandboxed local storage to put its game into it and a internet access (and maybe mic access), that's it.
I really hope Flatpak and something similar for Window becomes the norm, the current situation is a security and privacy disaster.
There can still be exploits of course but now you have the find a weakness both in the app + in the OS sandbox which is a whole lot harder
What year is it? To me prehistoric means buying a nice big box with a CDROM or some floppies and installing with no internet required at all. Shell exes that want to download crap is the current nightmare we are living in I thought.
[1] https://amonitoring.ru/article/onemore_steam_eop_0day/
Dead Comment
Valve...I have your software installed. It has a hole. Fix it.
This mudslinging isn't helping your PR or making me feel more secure about my steam install regardless of the details.
I basically uninstalled Steam client after first 0day was found. At least with gog I don't have install galaxy. But thats a different rant..
I know this will be unpopular with folks like tptacek, but I've always felt strongly that bug bounty programs offer too many perverse incentives to all parties.
More often than not it becomes a tool for companies to sweep issues like this under the rug and then use HackerOne's system to force the reporters to play ball (because they want to keep getting paid). I hate this sytem.
I'm 100% behind open, public disclosure and if it were my own product in question, I would offer bounties for _public disclosures_. That keeps everyone honest.
Now they can hide it for months(ever) allowing others to discover them and keeping the researchers quiet.
- Researcher finds bug
- Researcher discloses to vendor
- Vendor fixes (or not)
- Researcher discloses bug publically once vendor has fixed, or after X time (whichever is first)
This is roughly how Project Zero goes, and it's a good mix between giving the vendor the opportinity to fix it and deploy the update before it gets exploited.
It's very naive to assume that bugs can be fixed before others can exploit them. Bugs take time to fix, and the process takes time, especially when dealing with large enterprises.
While there are some DRM-free games, majority of games on HumbleBundle are sold as Steam keys, so you still need Steam to launch them.