Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Researcher banned on Valve's bug bounty program publishes second Steam 0-day

zdnet.com

Post reply on HN
Print view View original

141–150 of 214 posts

Re: Researcher banned on Valve's bug bounty program publishes second Steam 0-day

#141

Post by [deleted] »

Dylan16807 wrote: post #129
EnFinlay wrote: post #127

Earlier quoted context omitted.

I'm having trouble articulating this, so bear with me. In general, having a Bug Bounty program is good. We can agree on that, right? Most Bug Bounty programs have a scope, and staying inside the scope is important to the business for reasons . My guess is that most scopes are defined by a combination of confidence in the security of the code, resources to triage vulnerabilities in that part of the code, and the risk…

> Most Bug Bounty programs have a scope, and staying inside the scope is important to the business for reasons. Scopes are fine. But if it wasn't in scope, then clearly none of the program's rules apply to the bug, right? That bug isn't part of the program.

[deleted]

Re: Researcher banned on Valve's bug bounty program publishes second Steam 0-day

#142

Post by manwe150 »

jay_kyburz wrote: post #107
yorwba wrote: post #64

Earlier quoted context omitted.

> HackerOne should start requiring companies pay researchers for duplicates That would create a perverse incentive for researchers to tell their friends about the vulnerability so that they can resubmit it and also get a bounty. The problem could be solved on the side of the researchers by splitting the bounty among all submissions of the same bug, but anyone else with access to the report (employees of either Hacker…

I like your first idea of splitting the bounty. I think its unlikely employees of HackerOne or the relevant company would risk their job for a small share in a bug bounty.

I wonder if you could scale it so that the goal behaviors were also a market equilibrium. So no complicated prohibitions for going public, but each additional report (aided easily by going public) would cut into your own earnings some percentage. But on the flip side, each additional report costs the company money too, so they have monetary incentive also for pushing a fix before someone else finds it or you decide to give up waiting and go public with it anyways. With each on appropriately decreasing scales so there’s always appropriate minimum and maximum payouts.

I assume it'd be hard to convince companies it may be in their better interest to set up an incentive structure this way. But perhaps a third party platform could find some such mutually beneficial equilibrium.

Re: Researcher banned on Valve's bug bounty program publishes second Steam 0-day

#143

Post by tptacek »

chris_wot wrote: post #85
daeken wrote: post #78

Earlier quoted context omitted.

There is definitely politics involved, but not H1 internal. The issue is that every program handles disclosure itself, so H1 itself doesn't really have the power. That could be changed at a policy level, but I'm not sure that'll happen (or should happen, honestly; I don't really know where I land on it).

H1 could make it a proviso if using their service that rejected but reports are automatically disclosed.

1. The overwhelming majority of rejected H1 reports are garbage.

2. It is not the case that all reporters want their findings disclosed publicly, even if they're rejected.

3. Reporters already retain the right to publish findings however they'd like. The worst H1 or a client can do is kick you off the platform.

4. A bug bounty platform that mandated disclosure of any sort would lose all its customers to the platform that didn't have that mandate.

Re: Researcher banned on Valve's bug bounty program publishes second Steam 0-day

#144

Post by tptacek »

rodgerd wrote: post #130
Mindless2112 wrote: post #57

Earlier quoted context omitted.

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).

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.

If you don't want to participate in bug bounties, don't participate in them. It's not like it's hard out there in 2019 for application pentesters. This is a "world's tiniest violin" argument.

Re: Researcher banned on Valve's bug bounty program publishes second Steam 0-day

#145

Post by tptacek »

jay_kyburz wrote: post #107
yorwba wrote: post #64

Earlier quoted context omitted.

> HackerOne should start requiring companies pay researchers for duplicates That would create a perverse incentive for researchers to tell their friends about the vulnerability so that they can resubmit it and also get a bounty. The problem could be solved on the side of the researchers by splitting the bounty among all submissions of the same bug, but anyone else with access to the report (employees of either Hacker…

I like your first idea of splitting the bounty. I think its unlikely employees of HackerOne or the relevant company would risk their job for a small share in a bug bounty.

Splitting the bounty does nothing to fix the incentive problem, since it's the same outlay from the vendor whether they fix after 1 report, or a year later after 20.

In reality, vendors (or at least, serious vendors) aren't gaming H1 to stiff bounty hunters. If anything, the major complaint vendors have about H1 is that they aren't paying enough --- that is, they deal with too many garbage reports for every report that actually merits a fix.

Re: Researcher banned on Valve's bug bounty program publishes second Steam 0-day

#146

Post by ntw1103 »

StavrosK wrote: post #119
cprecioso wrote: post #112

Earlier quoted context omitted.

Steam's DRM (CEG) customizes the executables so it won't play without the Steam client running and logged in to the correct account. There are lots of not-DRM-enabled games on Steam, but they're decidedly in the minority.

That's why GOG.com is my first choice. They even provide a nice Steam-like installer (unfortunately, no Linux version of the installer), while letting you download your games DRM-free, archivable and standalone.

Not all of the games on GOG are DRM-free at this point. Some require GOGGalaxy, their version of the steam client. I went through a frustrating refund process after learning about this after making a purchase.

Re: Researcher banned on Valve's bug bounty program publishes second Steam 0-day

#147

Post by jessaustin »

burk96 wrote: post #72
jessaustin wrote: post #14

Earlier quoted context omitted.

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.

It would probably be better just to have a separate partition with a separate OS install. Either way, as you indicate, this is an unusual imposition on the user. Valve are holding themselves to a much lower standard than one would expect.

Re: Researcher banned on Valve's bug bounty program publishes second Steam 0-day

#148

Post by chii »

sushisource wrote: post #116
mordae wrote: post #62

This sucks. We run steam on some public PCs with unprivileged accounts and we wouldn't be very happy to find that users were able to gain admin access and steal other people's passwords through a keylogger. Sigh.

That seems to me the most obvious problem use case here. How can Valve possibly think that isn't important?

because their security model is too myopic. By defining security vulnerability to be only remote code execution from within the steam client, they save themselves a tonne of work (and cost).

I can understand that perspective - steam can't spend the time to rewrite to fix the EoP/LPE issues. Their stance must be that the user has to "be careful" not to install malware or other vulnerable software, instead of fixing steam.

Re: Researcher banned on Valve's bug bounty program publishes second Steam 0-day

#149

Post by babuskov »

ntw1103 wrote: post #146
StavrosK wrote: post #119

Earlier quoted context omitted.

That's why GOG.com is my first choice. They even provide a nice Steam-like installer (unfortunately, no Linux version of the installer), while letting you download your games DRM-free, archivable and standalone.

Not all of the games on GOG are DRM-free at this point. Some require GOGGalaxy, their version of the steam client. I went through a frustrating refund process after learning about this after making a purchase.

I have yet to find a game that absolutely requires Galaxy. Could you share which game was it?

Re: Researcher banned on Valve's bug bounty program publishes second Steam 0-day

#150

Post by batatati »

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

Post reply on HN