Hacker News new | ask | show | jobs
by EnFinlay 2487 days ago
I'm not trying to defend Valve, I'm just surprised that everyone seems to be so upset about the ban.
2 comments

Your first post acted like people were calling the ban unexpected.

Your second post acted like people were calling the ban not-allowed.

Neither is accurate, so your surprise is misplaced.

Even though it was clear that this might happen, it's such a blatant bad decision, for both ethics and customer security, that people are fighting back loudly.

You haven't given a single reason people shouldn't be upset by it.

I don't know how many people care about the ban, per se, but Valve's strategy here is an extremely bad and pointless one.

Was Valve technically within their rights to ban this researcher? Sure. Was it a move that advanced Valve's interests in any way? Obviously not.

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 to the business from vulnerabilities found in different parts of the code.

That is to say, I suspect that either Valve doesn't have many developers well versed in that part of the code base, or they are not confident in the security of that code base, or they considered it a low priority (even if we disagree about the priority of this vulnerability).

Now, let's pretend that I'm right about those reasons. Even further, let's pretend that they did not include it in the scope because they don't want to pay a bunch of bounties on code they knew was insecure.

(Aside, I'd much rather have companies only include things in bug bounty programs once they're confident they are secure, relying on BB to do your security for you is begging for trouble because then the company isn't taking responsibility for, or even trying, to do things securely)

Given this train of thought, which is making more than a couple assumptions, I don't think their actions are extremely bad or pointless. They are trying to keep their bug bounty program in scope. Bug bounty programs involve a fair amount of trust. If that trust is broken and they don't want that researcher anymore, then that's fair.

There probably should have been better communication. It probably (definitely) shouldn't have been a WONTFIX. Overall, terrible outcome for everybody.

It's just one of those things where every decision looks reasonable in isolation and leads to a really bad outcome and the company looking terrible.

Exclusions from a bug bounty are a part of the game, but if something is excluded, you—as the entity excluding it—can't reasonably demand secrecy re: an out of scope bug. You either accept that you're going to eat a reputational hit (and likely be forced to fix the exploit anyway) or make an exception to your policy.

If Valve wanted to try and defend the structure of their bug bounty program by essentially arguing that Steam is such a mess that local privilege escalations are out of bounds, they should be forced to publicly reckon with that stance.

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

Valve is free to define their own scope, but as a user, I'd expect them to place a big fat warning if it means any user on the system with Steam installed could get root. Their currently defined scope goes against user expectations of security.
What trust is involved in this instance? No special access was given to the researcher AFAIK. Anyone with the skills and interest could have found the bug, regardless of the bounty program. The bounty in this case seems like an incentive to report instead of selling an exploit.