Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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 to search for them.



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.


Yes, I got the impression they'd been trying to build & secure a shared-process sandbox for customer-supplied logic, and have now given up on that and (wisely IMO) moved to a separate process model.

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


More expensive to discover, but less valuable to discover. It's harder for white hats to find them, so you gotta pay more if it's important, but it's also harder for blackhats to find them, so it's less pressing to find them quickly.


I suppose because the vulnerabilities would actually be vulnerabilities in someone else's code they don't feel it should come under their umbrella?


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 party and what are the odds of that.


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 into things from my own project (100%) and things from other projects (10%).

The fact they haven't done this suggests to me that they consider the bounty system too expensive - either in payouts or maintenance. By reducing payouts you will likely reduce interest and increase signal to noise at the cost of less signal.


or send the signal to other less well intentioned parties who see the value of owning vulns to popular underlying libs


I don't know how strong that argument is, yet I suspect not very.

The problem with selling to 'less well intentioned parties' is that they are hard to get a hold of, hard to trust, and time consuming to work with. I very much doubt that many people who sell to them are not already close to them and their ilk. I also see this much like the arms trade, where illegal trading is an intrinsic property of the trader, not a function of the market.


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?


Very funny


Imagine someone compromises your system and downloads the PIA of all of your customers. Does it really matter where the exploited vulnerability was in your stack? The business effect is the same: your customers are still pissed at you.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: