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).
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).
From what I see, your value proposition is both to bug bounty hunters and to companies who see a value in having Hackerone manage their bug bounty program.
This effect (no matter the cause) of incident is about the worst thing that could happen to a company whose value proposition is that. It's like the bad old days where companies would legally threaten you if you found a bug, and from an outside perspective, Hackerone seems to promote it.
If I were an ethical hacker, I'd think twice before using your bug bounty program for fear of that treatment.
If I were a potential customer (or even a current customer), I don't know if I'd want to be associated with a company that tolerates veiled threats against ethical hackers.
"The worst H1 or a client can do is kick you off the platform."
As a hacker on hackerone, this is not my understanding of the relationship. Generally speaking the programs give you "authorized access" under the CFAA conditional on following the disclosure guidelines. I don't know about for other countries, but for the US I'm pretty sure this means that breaking the guidelines means you've retroactively committed a felony.
Now seems a little questionable about if any federal prosecutor would actually take the case, but it definitely doesn't seem like a strictly civil issue to me.
CFAA could (and likely would) apply for remote vulnerabilities i.e. exploiting SQLi on someone else's servers; but in the case of local privilege escalation like this particular case all the exploiting/testing happens on systems owned and controlled by the researcher, so it doesn't violate CFAA and doesn't need any permission from Valve - the breach happened with authorization from the system owner.
You need permission to pentest someone else's systems, you don't need permission to pentest software on your own systems even if that software is written by someone else. In an enterprise setting it's possible that you have signed a contract where you agree not to do such testing or not to publicize its results; but violating that would be a civil matter regarding the terms of that contract, not a felony in respect to CFAA.
I agree, if you're testing someone else's website or servers, you should comply with the scope and disclosure rules or not do the testing, unless the vendor has something else on their website that implicitly authorizes testing (like an email address to send reports to).
But that doesn't apply to Steam; nothing they write can really impact your ability to conduct security research on your own computer.
Yeah, agree in this specific case about local research (baring DMCA issues). Most H1 scopes seem to be remote targets as opposed to downloadables though.
I'm having trouble thinking of a single researcher that has left the US for legal reasons. There are lots of researchers now in Southeast Asia! But that's because bounty programs like H1 let those people work remotely.
Among other reasons, because the site is literally stuffed to its gills full of people reporting bullshit security issues, like "user impersonation possible" (if you convince a user to open developer tools and give you their session cookie), and H1 wouldn't be doing any good if it generated a constant stream of people "WONTFIX-disclosing" those reports.
I don't quite follow this reasoning. Are you saying that by allowing people to make their NA / WONTFIX reports public, it will dilute the H1 brand? Does association with H1 have a significant effect of the perceived legitimacy of individual public disclosures? Why does this matter?
My presumption is that the "other reasons" are business/political and centered around the desire to provide value to or establish goodwill with corporate partners.
People can publish whatever they want, and the only thing H1 can do about it is disinvite them from their platform. But anyone who suggests that H1 encourage people to publish NA/WONTFIX bugs probably hasn't had much contact with H1 bounty reports.
In reality, valid bugs being quashed by vendors is not the real problem H1 has.
I would rather suggest that H1 discourage (or even prohibit) their partners from dis-inviting reporters for publicizing NA/WONTFIX bugs.
In this particular case, is sounds like H1 (or an employee thereof) actively discouraged disclosure, which seems like a problem.
> In reality, valid bugs being quashed by vendors is not the real problem H1 has.
There can clearly be more than one problem. I still fail to see the relevance of the "bug report quality" problem to this discussion (beyond explaining why automatic disclosure of NA/WONTFIX reports is not helpful.)
You're probably outside the security sphere, but H1 is already taken seriously. There is no per-requisit for them to do so to be taken seriously as you state.
There comes a moment when inaction translates to deception, and if you need clarification for what that looks like in the wild, look no further than Facebook.
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.
It's still interesting to hear comments like in the GP for an unknowing person like me.
Your comment is interesting as well, if only for the defensive reaction without addressing the "being scummy" claim. I'm basically hearing, yeah it's scummy, now get off my lawn.
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.
Not sure what you're getting at. There's very few things we need, sounds like they're sacrificing a little to avoid giving a company they deem unethical any money.
I love games and can’t play my steam collection now. But if I have to give that up so that some silly bug elsewhere in my system doesn’t expose me to a ransomware attack (or worse), so be it. I’ll find another way.
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.
There are a number of tools called “steamworks emulators” that allow one to bypass this outright for many games. These are generally seen as piracy tools, but there’s no good reason you couldn’t use them when you wanted to play your purchased game collection without DRM.
Be a bit careful when experimenting, though. You may run into problems syncing your cloud saves for some games if/when you go back to the official client.
As you'd expect there are (or were, a few years ago when my account was temporarily banned for a few days) cracks to unlock the executables. You might need Steam still installed for this to work the first time, I'm not sure.
Legally I don't know where that stands, but morally I'd say we have a right to play the games we paid for.
Uhg, this drives me nuts. Apparently I'm not allowed to play Sepiko: Shadows Die Twice while traveling outside of the country. A VPN can temporarily get things going again, or staying in Offline mode, but what a pain in the ass...
Nope, that won't work for most Steam games. However, that's why there's GOG (gog.com), DRM free games. You can download the game installation kits using your browser and if you ever decide to stop accessing their site (or stop having access to the Internet) you can still play/install downloaded games.
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.
I submitted an XSS on the tesla website to hackerone, it was marked as a duplicate. A week later, shared it with an XSS mailing list and got an angry email from HackerOne soon after. Public disclosure violates the terms of their reporting program EVEN if they reject your report.
I'm really curious how much of what is reported to HackerOne ever gets and actual patch. It kind of seems like there are bunch of known vulnerabilities idling on their platform without quick fixes. Should be interesting once the HackerOne database is inevitably leaked.
HackerOne should start requiring companies pay researchers for duplicates - that the company already knew of a flaw should make them more liable, not less.
> 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 HackerOne or the relevant company) could try to get a share by having someone create a duplicate report.
First come, first served seems like it would be the hardest to game, as the first reporter is guaranteed to have actually done the work (not counting rogue employees who create bugs to "find" and report).
There should probably still be some kind of reward for duplicate reports to avoid discouraging researchers, but something symbolic like publicly acknowledging that they found a bug might be enough to provide validation.
> First come, first served seems like it would be the hardest to game
For external parties, yes. However it's the easiest to game for those liable, since you can just mark whatever you want as a "duplicate" and refuse to pay the bounty.
Offering bounties for public disclosures helps remove a lot of perverse incentives.
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.
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.
If they get a duplicate report they should let you know the disclosure timeline and keep you posted on progress fixing it. If they're not doing that they have no right to prevent disclosure.
It seems weird that HackerOne put themselves in such a deeply loser position to try to be the ones to prevent submitters from revealing security issues. Why not be a neutral party, and let the companies try to enforce rules on the hackers in these cases?
Eh that one is on you I think. How long did you wait? If we have 5 researchers report the same vulnerability in 30 days we're going to count it as duplicate and still expect to have a full 60-90 days from the first report to deploy a fix.
It was pretty low hanging fruit. I was going through an XSS tutorial and used their site for practice. `<script>alert(1)` could be saved into several user fields including Name and would then be executed on every subsequent pageload around the site.
If there was some indication that someone had reported it recently I maybe would have waited longer, but I suspect this bug had been known for months.
> 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.
Even in the scope of the original comment, doesn't it create a pretty perverse incentive to allow companies to mark HackerOne bugs as WONTFIX and then ban researchers who disclose them?
Isn't security through obscurity largely to be avoided? I thought the working model for most security researchers was: if it's not worth fixing, it's not worth hiding.
More to the point, I thought that responsible disclosure always came with an expectation of public disclosure. The advice I've always been given is that you should never disclose with conditions -- ie. "fix this and I won't tell anyone."
It should always be, "I am going to tell everyone, but I'm telling you first so you can push a fix before I do."
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.
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.
Disable the Steam service. Run Steam only on a separate user session with limited rights (no admin and no access to your files). So essentially you'd have to manually switch user, via the login screen, to play your games.
As far as I'm aware, Steam makes its own folder writeable by everybody. Besides, you should get an error instead of the UAC if you're running as a non-admin account.
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.
It's a Steam issue, given that background services don't have to run as SYSTEM, and yet Valve decided to have Steam's background service do precisely that.
Thankfully, the Linux version doesn't seem to have this problem (AFAICT).
I think it should become a Windows/Microsoft issue, to be honest. A good example is the recent Zoom vulnerability, the software made it possible to perform certain exploits on the user and operating system, so Apple stepped in and disabled the exploit. In this case, I think Microsoft should do the same in order to protect their users. My guess would be that the install base of Steam on Windows is as least on par with Zoom on macOS, if not many times larger.
In the end, Microsoft will get bad reputation for having an insecure OS (not to even mention Valve here, and in the long run it will hurt them as same as it did Adobe with their Flash stubbornness).
True; it'd be really nice if Microsoft started deprecating running non-essential things under the SYSTEM user. Windows could/should emulate the OpenBSD strategy of running services/daemons as unprivileged users dedicated to those services instead of as root.
Windows does support this functionality, and ultimately Valve's to blame for not using it, but you're right that Microsoft should be more proactive in encouraging good design and discouraging bad design.
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.
This also has nothing to do with Flash specifically, rather as you said Adobe's policy. It could have been any software but especially for Flash.
Flash was just such a unique special target, ala PDFs and Microsoft word, there were few wide open targets from which a hacker could predictably get the user to open (whether embedded or not) on a targets machine. So it was particularly sensitive to vulnerabilities by design, where a much broader security perspective was clearly needed than most software.
I'd prefer to describe it as slashing a dead horse's rotten corpse with a katana. As the bloat and flesh of the ecosystem has disintegrated we're able to observe the framework more clearly - the bone structure of the horse, if you will. Using the katana we are making precise, incisive blows to the remnants as we extract meaning from it's corpse - or lessons learned, if you will.
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.
I would think it would work in practice closer to mobile apps, where their access requirements are explicitly stated upfront (eg: needs access to documents folder).
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]
Telling a security researcher "we're not going to fix this but please keep it secret" is not a viable strategy, ever.
In the end, the researcher went public (as nearly all will, in that same situation), Valve got a hit to their reputation in the tech press, and they ended up having to (attempt and fail to) fix it anyway. Entirely predictable, and Valve looks really stupid here.
Banning people from your bug bounty problem for following the generally-accepted rules for security disclosures is certainly with in their right, but so what? It's not a winning strategy for any company.
What's the point of stating these obvious tautologies? Yes, they have that right, he has the right to post on Twitter, someone has the right to post that on HN, we have the right to call Valve out, you have the right to defend Valve, we have the right to reply to your defence, and so on ad inf.
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'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.
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.
Did you read his first report? In scope or not, their right or not, how is a ban without proper dialogue (threats don't fall in that category) the reasonable reaction here? That's not how you interact with a pretty tight knit community, even if you're the one sitting on the pile of money.
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.
Why is it whichever is first and not after a fixed time? I see a benefit to waiting X time regardless, because it allows more time for the patch to circulate to everyone. What is the benefit to disclosing it immediately after it is "fixed"?
It's typically not immediately after it's fixed, but usally about a week or so, to let the majority update.
The vendor can also usually request an extension, as per the Project Zero guidelines, of I believe 1 month if they confirm to be actively working on a patch.
The goal of responsible disclosure is to help the vendor and their users' be more secure, so having a policy that is balence between the two is important to let the vendor fix it, and to not let the users be possibly hacked
It's generally not possible to release a fix without effectively disclosing the vulnerability. It's just too easy for people to deduce what the vulnerability was by looking at the patch.
The vulnerability can often be discerned from the patch. Burying it amidst lots of unrelated bogus changes and not calling out its security relevance is going to annoy your users.
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.
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.
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.
This wouldn't be anywhere near as severe a problem as it is if Steam's service wasn't running as something as ridiculously privileged as NTAUTHORITY\SYSTEM.
On the plus side, reading the writeup [0] it seems unlikely that this affects the Linux client (or even if it does, it's at least limited to the current user account). So I guess Steam can continue to live on my machine for another day.
I'm amused that anyone does not have a cynical view of H1. H1 is an equivalent of HR for cyber. It exists not to deal with issues or address problems, rather it exists to help companies to manage bad exposure. That's how H1's bread is buttered.
I wonder if this is a product of Valve's free-form company structure. If as a Valve employee, you have the autonomy to float between projects, how do you maintain a strong security team? Do they even have a dedicate security team?
I've worked with extremely competent security professionals before. Those people love and are fanatical about security. Based on my experience, it seems a near certainty that Valve doesn't employee even a single such person. These people raise hell if security is ignored and have a job freedom that makes typical software engineers look like panhandlers.
Let's remember that Valve is the oldest there is in a business they pretty much pioneered with Steam over 15 years ago.
As somebody who's had an account there since day 1, I'm still amazed by how tight they've managed to keep their ship for all these years, even tho plenty of people have been trying to break into that very worthwhile target for over a decade.
If I contrast that to my experiences with services like Uplay, and Origin, then those differences are like night&day, because with both my accounts on these services I had lot's of issues due to my accounts getting hijacked (probably trough support) several times.
In 15+ years of using Steam, this hasn't happened once to me, so whatever Valve is doing at that end, it seems to have worked well for them and their customers.
That's not meant to defend their stance on this particular issue, but imho it's also kinda dishonest to now frame Valve as a company where nobody cares about security.
If that'd be really the case then they would have gone out of business over a decade ago.
Since Valve stopped producing games, I wonder what their net income per employee is based on assets they own less revenue produced by third-parties through Steam.
If you look at just the assets Valve produces minus rent seeking, are they losing money?
Valve figured out how to print money by hooking teenagers with gambling on loot boxes. They stopped having to create AAA titles, they stopped having to do anything remotely creative, and now they are a giant cancer with no value left to add. Their client is an insecure, slow, instable piece of shit and has been this way for well over a decade. I regret being a customer of theirs.
I remember listening to some of their commentary tracks where the employees talk about how their desks had wheels, there's no managers, and there's no deadlines and no stress. They also at one time had higher profit per employee than Google! [1]
Turns out that all along having no accountability in your company would result in complacency and a critical lack of production. I'm curious to see how Valve Software as a company is going to climb over this security wall they've found themselves in front of if seemingly nobody has to answer to anyone and everybody gets to do what they want in a leisurely fashion. I mean we give Chinese IoT vendors crap all day long, and it turns out Steam might be just as bad!
I heard somewhere it's very stressful, toxic politics and so on. Not sure where but it's interesting to see a report to the contrary.
Personally I always thought it would be cool to work at Valve, but not anymore. I don't see them doing anything broadly relevant that doesn't involve coasting on the momentum/market share of ancient products. Their VR stuff is cool, but even there it feel like they're lagging behind e.g. Oculus in ways that matter.
It's a premium product, and if I were going to buy a new VR headset right now it'd be the Index, but it's not a generational leap (it's basically a Vive++) and I've lost confidence in Valve to produce such a leap, let alone to bring VR gaming to the mainstream.
I'd love to be proven wrong, because I dislike Oculus. I am simply stating my observation that Valve seems to be in decline.
From what I've read, the original bug involved malware already installed on the PC using the Steam client to run other code. While I'm not a security expert in any way, that doesn't seem to me like a huge exploit. If the attack requires installing malware on the victim's computer, why not just do the evil stuff directly with that malware? If that's the case and I'm not just remembering it wrong, then I could see why Valve wouldn't want to pay up and could see why this guy would go on a social media rant to slander Valve either hoping they'll pay up or just to get petty revenge.
Lets say you and your brother share a PC, but you're the admin. You both play Steam. His account has no password. I steal the laptop. I log in as him. I pop a SYSTEM shell using Steam. I reset your admin password.
Wouldn't you be able to do the same simply by looking at the file system without any access to admin privileges?
I'm not arguing that this vulnerability isn't one, it's a privilege escalation vulnerability, however in your situation you got physical access which is as far as I know, pretty much game over for your system.
Not if they haven't granted access to the files to you. In fact by default the files in a user's home folder (including Documents, Videos etc.) are inaccessible to other (non-privileged) users on Windows.
This is true, and also why I lock down my BIOSs and set the OS as the only boot device. TRK is a bootable portable linux specifically for resetting and unlocking local admin accounts.
Encryption, however, cannot be broken without your credentials. These can be obtained from default running instance of Windows with Mimikatz if the admin credentials are still in memory from an earlier session.
Yeah, there are definitely ways of securing versus someone with physical access, but I expect most machines with a non-sandboxed steam installed probably don't have them.
This privilege escalation attack is probably never going to be used if the attacker has physical access.
> In fact by default the files in a user's home folder (including Documents, Videos etc.) are inaccessible to other (non-privileged) users on Windows.
Sure that's certainly right but physical access doesn't force you to be "on Windows".
> This is true, and also why I lock down my BIOSs and set the OS as the only boot device.
I never talked about you specifically, you are a tiny tiny minority. Even then, that just block your computer. If you can't bypass that BIOS (seriously doubtful), the hard drive is still accessible.
> Encryption, however, cannot be broken without your credentials.
Is there an encryption on by default? That must be new because I'm pretty sure I never had trouble to access my user folders on some of my old Windows 7 installation (that's would be a good 20% of Steams users).
I can't find anything about this, if I have time tonight I'll try to see if I can access my user folder through another OS.
> And Windows has useful account-based file encryption too.
Is this on by default on Windows? I haven't needed to access my files from another Windows installation for a long time, but I'm pretty sure the last time I tried on my good old hard drive with Windows 7, they weren't encrypted and I had no trouble to access them.
> No, but it only takes a minute to turn on if you're going to be sharing unsupervised access to a computer.
This is not something that 99.99% of Steam users would do though...
It would still be possible to retrieve the encryption keys too if the PC is still running (which is also the only ways to make Steam vulnerability viable) using a can of compressed air [1].
As I said, physical access to a computer is pretty much already game over... The Steam vulnerability is quite useful while being connected remotely though (which is really the most likely scenario either way).
> 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.
No, using this 0-day malware, with lower privilege level, could do stuff it could not do.
From Microsoft's perspective, they consider local privilege elevation on a client computer an "important" vulnerability that requires patching and paying a bug bounty:
If Microsoft considered privilege escalation to be serious, they wouldn't have Windows setup a single privileged account on a fresh install. Or at the very least, they wouldn't make it necessary to jump through two hidden hoops to make a separate admin account without (a) a Microsoft profile and (b) without "secure questions" misfeature.
b) Researcher reports vulnerability that falls under X
c) Since it's out of scope, it's closed as N/A
d) Report is locked because company doesn't want to publicly disclose a vulnerability in their system via the Hackerone platform
What's the problem here? Just go with normal vulnerability disclosure. Bug bounty programs are a two way street, and respecting the scope is part of that.
Edit: I guess the important part is that the researcher was then banned for disclosing the report. Seems reasonable, honestly. I don't agree with it, but I understand it.
Acknowledgement is one thing. Disclosure is another.
If Steam had no problem acknowledging that this functionality exists, they should have had no problem with it being disclosed. There lies the problem. In the bathroom with the needle in their arm; "...there's no problem here..." but if you swing the door open they'll still try to shut it. Because they know they're wrong.
If HackerOne isn't going to help you they have no right to hinder you. If they want to strongarm everyone into effectively the same agreement as an NDA then there literally is no point in turning vulnerabilities into HackerOne.
They seem to only exist as a cow-catcher on the locomotive of software vendors too lazy to actually fix crappy code.
"Who needs to fix code and shell out bounty if you can pinpoint and silence the researcher?"
> If HackerOne isn't going to help you they have no right to hinder you. If they want to strongarm everyone into effectively the same agreement as an NDA then there literally is no point in turning vulnerabilities into HackerOne.
The article gets this part wrong: the hacker isn't banned from H1, which he says in his blog post -- "Eventually things escalated with Valve and I got banned by them on HackerOne — I can no longer participate in their vulnerability rejection program (the rest of H1 is still available though)." HackerOne is in no way punishing the hacker for his reports and/or public disclosures, for what it's worth.
(Disclosure: I am on the community team at H1, though I've had effectively zero involvement with this.)
You can define whatever you want for your project's scope, but when you're distributing self updating binaries to an audience the size of steam's and you act this casual about an admin escalation exploit, you deserve whatever damage to your reputation that you get.
Thing is, as a result of the ban the next disclosure was immediately public. This left more people vulnerable than the responsible disclosure method would have.
Hence, this practice by steam makes all users of steam less secure (doubly so as they actually don't want to fix these issues). This is something the public deserves to know, so they can act accordingly.
Bug bounty programs exist primarily for the companies’ benefit. If you do not respect the security community, the best you can expect is for researchers to publicly disclose the vulnerabilities. At worst, black hats will find them and sell them since they can be very valuable.
Retailiated as in he was banned from their bug bounty program. The program with a scope that they went outside of. I think it's reasonable to be banned.
Obviously it would be better if Valve fixed the issue and gave a (possibly reduced due to out of scope) bounty.
That makes sense if the application is, like, a SAAS app, and the scope is, like, "don't employ credential stuffing or test any of our 3rd party dependencies that have not given us permission to be included in this scope".
But this is software people install on their desktops, and Valve has no say in how security researchers approach that stuff. Valve can and maybe even should exclude LPEs from their bounty scope (if that's not what they're focusing on right now), but they can't reasonably ban people for publishing vulnerabilities they've scoped out of the only mechanism they've provided for submitting and tracking vulnerabilities.
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.