Slashdot Mirror
Are Bug Bounties the Right Solution For Improving Security?
saccade.com writes Coding Horror's Jeff Atwood is questioning if the current practice of paying researchers bounties for the software vulnerabilities they find is really improving over-all security. He notes how the Heartbleed bug serves as a counter example to "Linus's Law" that "Given enough eyeballs, all bugs are shallow." "...If you want to find bugs in your code, in your website, in your app, you do it the old fashioned way: by paying for them. You buy the eyeballs.
While I applaud any effort to make things more secure, and I completely agree that security is a battle we should be fighting on multiple fronts, both commercial and non-commercial, I am uneasy about some aspects of paying for bugs becoming the new normal. What are we incentivizing, exactly?
NSA is buying security holes to use against us. This is part of what Snowden revealed with the leaks.
Offering a bounty, even though it is not as much as the security problem could fetch on the grey market, creates a certain loyalty towards the vendor, and makes it easier to go to them, and ensure the hole gets patched. It also attracts more eyeballs to your software, as finding a problem means money. Google has gone even further - by offering grants for research into specific products, where you get money for checking security of the software, not just finding security prolems.
So I believe it is a good thing; it probably means more holes will be reported directly to the vendor, and not sold for exploit. It probably attracts eyeballs as well...
Assembling etherkillers for fun an profit
It pays better to exploit the bugs...
"A door is what a dog is perpetually on the wrong side of" - Ogden Nash
... He notes how the Heartbleed bug serves as a counter example to "Linus's Law" that "Given enough eyeballs, all bugs are shallow."...
I think the big issue with the Heartbleed bug was that the OpenSSL code base was so egregiously poorly written and maintained that eyeballs started bleeding whenever they looked at it. imo, the OpenSSL code base never had enough eyeballs looking at it to make its bugs shallow. It was painful to look at, so eyeballs avoided looking at it.
.
I still think that Linus' Law hold true, or at least is a very good guideline. I think exceptions like the OpenSSL code base are needed to hone the point that Linus' Law makes.
I also take issue with the headline, as I do not think there is any one right solution for improving security. The improvement of security is a multi-faceted endeavour and an ongoing process.
But that's the only way to fix code that's already been written.
No, but it is one pathway out of several.
Why aren't bounties considered a good idea? Yes, we've always argued that it gives developers an incentive to intentionally insert bugs so that they may profit off of them later. But are there any documented cases of that actually happening? For one, the authors of the code should automatically be prohibited from profiting by their mistakes. For another, there is a huge chance someone else would find and submit the bug first, and only the first finder should get rewarded. In human behavior, as a general rule, whatever behavior you reward, you create more of. It stands to reason that rewarding people for finding bugs will only result in more bugs being found!
I've abandoned my search for truth; now I'm just looking for some useful delusions.
You need to do your own debugging as well, but these days, security bugs are worth serious money.
A bug bounty is just recognizing that if only the black hats get any support, that's all we'll have in a while.
... is the best solution. Nothing gets them to fix the bug besides liability. The fear of lawsuits, embarrassment, etc... that gets them to take it seriously. Nothing else.
MS had some bugs that they knew about for a decade that they didn't patch.
You jump right to setting their nuts on fire.
I've decided to stop wasting my time responding to AC trolls/sockpuppets... so if you want a response from me... login.
But recent developments have made clear that securable hardware is sine qua non. All firmware must be in socketed memory, so that you can take it out and externally check it. You can't trust an untrusted system to check itself. All firmware must be protectable with a hardware readonly jumper or switch.
I know that this is inconvenient and a revolution on how hardware is currently made. but if people started demanding it en mass, it would not cost very much. And I mean the firmware in disk drives and optical media players and especially routers.
There may be other requirements.
This is sine qua non. Without this we have nothing.
I am reminded of a story on TheDailyWTF, The Defect Black Market http://thedailywtf.com/articles/The-Defect-Black-Market
In that short story, a company-internal bug bounty program worked as intended for a while, numerous bugs were found and resolved. When the QA testers ran out of bugs to find, they started conspirating with the developers: the developers started placing bugs so that the QA testers would certainly find them and get their bounty. The bug bounty program was stopped soon after.
So yeah, corruption and conspiracy are possible downsides of bug bounty programs.
It's either someone who will fix the bug or someone who plans to exploit it.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
This is only going to work if you can get all the security holes out of a piece of code. If you can't then people are going to find bugs and get really good at finding them.
Some of them might look to see if they can get a better offer than yours.
If pigs had wings. There is no such thing as secure hardware. There have been enough recent stories about backdoors in CPUs, hard-drives and so forth to know that this is very likely, if not true.
What I personally think is really scary is that a lot of devices in our PCs are ready to accept new firmware at any moment. There usually are no safeguards that I can enable to prevent malicious code being injected to core components like BIOS, CPU microcode, HDD, DVD...
Now, in general, hardware security is a tricky concept, because currently the hardware layer is simply fully trusted.
Any expense that scales with the job it does or problems it solves is a good thing. Why pay someone XX per hour to sort books in a book store if you can pay them $0.05 per book and ensure static, scaled costs that tie to inventory cycling (aka sales) directly. Then again, you don't know how many bugs are in your program.
i wish BIOS/UFI updates could only happen when a jumper was set. That is the safest way of doing things.
Stop making so many bugs, and fix them yourself.
You don't have to pay out if there are no bugs. So don't make them and your problem is entirely self-inflicted.
Back in the old days, you'd generally have to either replace the physical chip or at least move a jumper in order to write to firmware.
The current status quo is simply to lower costs for support; you don't have to send out a tech to update someone's firmware, you can just have them download a file and run it. Companies can save money on QA because you can fix mistakes later on. To make matters worse, the vast majority of consumers don't understand the problem.
I agree with you 100%, but this is money we're talking about. I could see a small market of locked-firmware devices targeted at entities that require that level of security, but it would be priced well outside consumer range.
Those who can't do, teach. Those who can't teach either, do tech support.
Good point. Practicality trumps security here.
Adding a write-protect jumper only costs a few cents.
And if you want to keep the convenience of downloadable upgrades, don't install the jumper.
Sure, only a few percent of us would buy a motherboard because the BIOS had the option to add a write protect jumper, but that's still a few percent more sales.
Plus it's a marketable difference - if you've got it and your competitors don't, then you can use scare tactics;
"Unlike our competitors, we care about your computer's health, that's why all our motherboards have physical protections against viruses."
What about better QA and no don't have the dev's do testing.
Also the QA needs to have full access to what they are testing. They need to be able stuff that end users can do as well being able to manually set up the system / data in different ways not only to make easier / faster to test out some modes but to also to setup for some unusual modes / settings.
QA needs to be able to think out of the box and it does not need to be some job that is just a side job to some ones other job.
back when you need to burn eproms code was better on release there where still updates but the base code. Even with older dos / windows game where mostly done on release with some updates. Now days things are more buggy and software comes out with things that will be added later with updates that are easy to install.
Well they certainly are better then thowing people reporting security holes to jail...
Of course it's possible. My company does it all the time. There are several effective methods, the simplest being putting a jumper on the write-enable pin of the device that holds the firmware, and the removal of that jumper before you ship.
...was covered almost 20 years ago by Scott Adams: http://dilbert.com/strip/1995-...
Adding a write-protect jumper only costs a few cents.
1cent times 1 billion devices is 10million "lost profit".
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
And 1 percent less sales * 1 billion devices * $100 a board is $1 billion in "lost profit".
If the jumper costs %0.1 of the profit on the device, then it only needs to improve sales by %0.1.
No you dont.
You just need the tools to calculate the firmware version, and a way to verify it is correct. This includes verifying alternate shadow copies, and being able to blank unused and unallocated storage, see engineering sectors etc.This includes video cards with direct DMA access.
There has been a strong push against firmware discovery. Part of the reason is people may work out they are getting older products, or with slower cpus, less modern displays ect out of the box.
Even if we did have firmware control, secret instruction sets, or port commands to other hardware, means that there are bleeds in other areas.
But a home brew router/firewall that drops packets on the floor makes the game harder, so physical access is needed. Oh wait, this is what airport snooping is about.
i gave up on chasing bounties and writs in general because once you get a lead on something someone far more skilled with far graver intent
just swoops in. best you can do is when they are coming for your chair torpedo the project.