11–20 of 80 posts
"It looks like your JavaScript is disabled. To use Hacker One, enable JavaScript in your browser and refresh this page." Kinda ironic that a site that is supposedly for hackers wants you to expose yourself to zillion browser vulnerabilities before you can see its content.
Shopify seems to basically have given up on application-level sandboxing, and now relies on process-level sandboxing (e.g. seccomp). This is probably wise; the track record of in-language sandboxing is pretty bad (see also: Java applets.)
we expect most vulnerabilities will no longer be exploitable without additional bugs in the kernel or seccomp itself, and so we are lowering the payout amounts for our program to 10% of previous levels. I don't quite follow this logic. If bugs are now going to be more difficult to find, one would think they would be more valuable, not less.. and that by lowering the bounties they are lowering the incentive for people…
They are still paying for them even if you don't have a sandbox escape, but less because it's. Ow less critical for their security.
Earlier quoted context omitted.
That's flawed reasoning IMO. Do they expect the underlying porject maintainers to have the same resources they do to compensate third party vulnerability research? It really should be the other way around, public facing, revenue generating projects should do all they can to subsidise vulnerability research and upstream their findings. The alternative would be to start paying up more for the code they use from third p…
Doesn't this assume that as each bug in MRuby becomes more difficult to find, they're also more severe? Couldn't it instead be the opposite, that each bug is less severe because all of the serious ones have been closed?
Earlier quoted context omitted.
That's flawed reasoning IMO. Do they expect the underlying porject maintainers to have the same resources they do to compensate third party vulnerability research? It really should be the other way around, public facing, revenue generating projects should do all they can to subsidise vulnerability research and upstream their findings. The alternative would be to start paying up more for the code they use from third p…
With those lower 'underlying project' bugs there are multiple actors who can compensate for vulnerability research, so the market rate goes down. It makes sense to either: lower the payout to reflect market rate or start a seperate scheme for those projects that others can buy into. Unfortunately if you use a seperate scheme you end up paying for bugs that don't affect you. Personally I'd have split my own payouts in…
"It looks like your JavaScript is disabled. To use Hacker One, enable JavaScript in your browser and refresh this page." Kinda ironic that a site that is supposedly for hackers wants you to expose yourself to zillion browser vulnerabilities before you can see its content.
'Cos a true hacker would be able to enable JavaScript without exposing himself.
we expect most vulnerabilities will no longer be exploitable without additional bugs in the kernel or seccomp itself, and so we are lowering the payout amounts for our program to 10% of previous levels. I don't quite follow this logic. If bugs are now going to be more difficult to find, one would think they would be more valuable, not less.. and that by lowering the bounties they are lowering the incentive for people…
No, the point is that vulnerabilities in MRuby (the scope of this bug bounty) are now less impactful for them. They are still paying for them even if you don't have a sandbox escape, but less because it's. Ow less critical for their security.
Last time I needed to do something like this, I just asked people to give me an AWS Lambda endpoint to talk to. "You want your custom logic, fine, run it in a container you're responsible for."
What you have to realize is how important Security is to Shopify. We are a trust based business to an extreme extend. We host the livelihoods of hundreds of thousands of other businesses. If we are down or compromised all of them can't make money ( as some of you saw during Black Friday, to the tune of $300k+ a minute at times ).
One of the best ways for us to augment our internal security team is to work with the white hat community. This was a pain before Hacker One but now is significantly easier.
One challenge is that Shopify (still) hasn't really got the profile in the tech industry that a lot of Silicon Valley local companies have. This is totally fine by me, but it's means that if a top white hat sits down and decide what to work on, we are not automatically top of mind.
So we decided to overspent as a kind of "marketing" investment. Hacker one is a classical two sided market place. There is plenty of supply of skilled researchers but also a lot of demand for their services. We want to be known for being one of the most responsive companies and also pay top dollars for top findings.
So the basic idea is that when we launch something new, we 10x the payouts to bootstrap the process of familiarization. We also provide a very convenient local environment for doing the work in. It should be more fun and more lucrative to make Shopify related discoveries then other companies. After this initial period we then reduce the payouts somewhere slightly above community standards. Its all just business 101.
Internally we are actually thrilled how the shopify-scripts/mruby program went. Most (all?) of what was found would have been caught by our sandboxing but we don't want to rely on this. As everyone who does security knows - lots of exploits, even if superficially contained, can sometimes combine into "the big one".
Giving your users a ruby interpreter inside your infrastructure is a terrible idea. They're just one unreported bug away from disaster!
One could think of a few alternatives, all of them involving decoupling Shopify's servers from users' scripts.
It could be anything from Docker/k8s to AWS lambda to a custom DSL. I'm not saying any option is easy - proper solutions tend to require effort.
Shopify seems to basically have given up on application-level sandboxing, and now relies on process-level sandboxing (e.g. seccomp). This is probably wise; the track record of in-language sandboxing is pretty bad (see also: Java applets.)
I was under the impression that JVM, CLR and probably e.g. V8 are reasonably secure. I'd like to learn more about recent sandbox-escaping vulnerabilities in these runtimes. Got any resources?