Forgot your password?
typodupeerror
Bug Security Software The Almighty Buck Technology

Bug Bounties Don't Help If Bugs Never Run Out 235

Posted by Soulskill
from the trying-to-bail-the-ocean dept.
Bennett Haselton writes: "I was an early advocate of companies offering cash prizes to researchers who found security holes in their products, so that the vulnerabilities can be fixed before the bad guys exploited them. I still believe that prize programs can make a product safer under certain conditions. But I had naively overlooked that under an alternate set of assumptions, you might find that not only do cash prizes not make the product any safer, but that nothing makes the product any safer — you might as well not bother fixing certain security holes at all, whether they were found through a prize program or not." Read on for the rest of Bennett's thoughts.

In 2007 I wrote:

It's virtually certain that if a company like Microsoft offered $1,000 for a new IE exploit, someone would find at least one and report it to them. So the question facing Microsoft when they choose whether to make that offer, is: Would they rather have the $1,000, or the exploit? What responsible company could possibly choose "the $1,000"? Especially considering that if they don't offer the prize, and as a result that particular exploit doesn't get found by a white-hat researcher, someone else will probably find it and sell it on the black market instead?

Well, I still believe that part's true. You can visualize it even more starkly this way: A stranger approaches a company like Microsoft holding two envelopes, one containing $1,000 cash, and the other containing an IE security vulnerability which hasn't yet been discovered in the wild, and asks Microsoft to pick one envelope. It would sound short-sighted and irresponsible for Microsoft to pick the envelope containing the cash — but when Microsoft declines to offer a $1,000 cash prize for vulnerabilities, it's exactly like choosing the envelope with the $1,000. You might argue that it's "not exactly the same" because Microsoft's hypothetical $1,000 prize program would be on offer for bugs which haven't been found yet, but I'd argue that's a distinction without a difference. If Microsoft did offer a $1,000 prize program, it's virtually certain that someone would come forward with a qualifying exploit (and if nobody did, then the program would be moot anyway) — so both scenarios simply describe a choice between $1,000 and finding a new security vulnerability.

But I would argue that there are certain assumptions under which it would make sense not to offer a cash prize program — and, in keeping with my claim that this is equivalent to the envelope-choice problem, under those assumptions it actually would make sense for Microsoft to turn down the envelope containing the vulnerability, and take the cash instead. (When I say it would "make sense", I mean both from a profit-motive standpoint, and for the purposes of protecting the security of their users' computers.)

On Monday night I saw a presentation put on by Seattle's Pacific Science Center "Science Cafe" program, in which Professor Tadayoshi Kohno described how he and his team were able to defeat the security protocols of a car's embedded computer system by finding and exploiting a buffer overflow. That's scary enough, but it was more interesting how his description of the task made it sound like a foregone conclusion that they would find one — you simply sink this many person-hours into the task of looking for a buffer overflow, and eventually you'll find one that can enable a complete takeover of the car. (He confirmed to me afterwards that in his estimation, once the manufacturer had fixed that vulnerability, he figured his same team could have found another one with the same amount of effort.)

More generally, I think it's reasonable to assume that for a given product, there is a certain threshold amount of money/effort/person-hours such that if you throw that much effort at finding a new security vulnerability, you will always find a new one. Suppose you call this the "infinite bug threshold." Obviously the amount of vulnerabilities is not really infinite — you can only do finitely many things to a product in a finite amount of time, after all — but suppose it's so close to infinite as to make no difference, because the manufacturer would never be able to fix all the vulnerabilities that could be found for that amount of effort. I'm sure that $10 million worth of effort, paid to the right people, will always find you a new security vulnerability in the Apache web server; the same is probably true for some dollar number much lower than that, and you could call that the "infinite bug threshold". On the other hand, by definition of that threshold, that means that the amount of vulnerabilities that can be found for any amount of money below that, will be finite and manageable.

(I'm hand-waving over some details here, such as the disputes over whether two different bugs are really considered "distinct," or the fact that once you've found one vulnerability, the cost of finding other closely related vulnerabilities in the same area of the product, often goes way down. But I don't think these complications negate the argument.)

Meanwhile, you have the black-market value of a given type of vulnerability in a given product. This may be the value that you could actually sell it for on the black market, or it may be the maximum amount of effort that a cyber-criminal would invest in finding a new vulnerability. If a cyber-criminal will only start looking for a particular type of vulnerability if they estimate they can find one for less than $50,000 worth of effort, then $50,000 is how much that type of vulnerability is worth to them.

Now consider the case where

infinite bug threshold > black-market value

This is the good case. It means that if the manufacturer offered a prize equal to the black-market value of an exploit, any rational security researcher who found a vulnerability, could sell it to the manufacturer rather than offering it on the black market (assuming they would find the manufacturer more reliable and pleasant to deal with than the Russian cyber-mafia). And we're below the infinite bug threshold, so by definition the manufacturer only has to pay out a finite and manageable number of those prizes, before all such vulnerabilities have been found and fixed. I've made a couple of optimistic assumptions here, such as that the manufacturer would be willing to pay prizes in the first place, and that they could correctly estimate what the black-market value of a bug would be. But at least there's hope.

On other hand, if

infinite bug threshold < black market value

everything gets much worse. This means that no matter how many vulnerabilities you find and fix, by the definition of the infinite bug threshold there will always be another vulnerability that a black-hat will find it worthwhile to discover and exploit.

And that's the pessimistic scenario where it doesn't really matter whether Microsoft chooses the envelope with the vulnerability or the envelope with the $1,000, if the infinite-bug-threshold happens to be below $1,000. (Let's hope it's not that low in practice! But the same analysis would apply to any higher number.) If the black-market-value of a bug is at least $1,000, so that's what the attacker is willing to spend to find one, and if that's above the infinite-bug-threshold, then you might as well not bother fixing any particular bug at that level, because the attacker can always just find another one. It doesn't even matter whether you have a prize program or not; the product is in a permanent state of unfixable vulnerability.

At that point, the only ways to flip the direction of the inequality, to reach the state where "infinite bug threshold > black-market value", would be to decrease the black market value of the vulnerability, or increase the infinite bug threshold for your product. To decrease the black market value, you could implement more severe punishments for cyber-criminals, which makes them less willing to commit risky crimes using a security exploit. Or you could implement greater checks and balances to prevent financial fraud, which decreases the incentives for exploits. But these are society-wide changes that would not be under the control of the software manufacturer. (I'm not sure if there's anything a software company could do by themselves to lower the black-market value of a vulnerability in their product, other than voluntarily decreasing their own market share so that there are fewer computers that can be compromised using their software! Can you think of any other way?)

Raising the infinite bug threshold for the product, on the other hand, may require re-writing the software from scratch, or at least the most vulnerable components, paying stricter attention to security-conscious programming standards. Professor Kohno said after his talk that he believed that if the programmers of the car's embedded systems had followed better security coding practices, such as the principle of least privilege, then his team would not have found vulnerabilities so easily.

I still believe that cash prizes have the potential to achieve security utopia, at least with regard to the particular programs the prizes are offered for — but only where the "infinite bug threshold > black-market value" inequality holds, and only if the company is willing to offer the prizes. If the software is written in a security-conscious manner such that the infinite bug threshold is likely to be higher than the black-market value, and the manufacturer offers a vulnerability prize at least equal to the black-market value, then virtually all vulnerabilities which can be found for less than that much effort, will be reported to the manufacturer and fixed. Once that nirvana has been achieved, for an attacker to find a new exploit, the attacker would have to be (1) irrational (spending an estimated $70,000 to find a vulnerability that is only worth $50,000), and (2) evil beyond merely profit motive (using the bug for $50,000 of ill-gotten gain, instead of simply turning it in to the manufacturer for the same amount of money!). That's not logically impossible, but we would expect it to be rare.

On the other hand, for programs and classes of vulnerabilities where "infinite bug threshold < black-market value", there is literally nothing that can be done to make them secure against an attacker who has time to find the next exploit. You can have multiple lines of defense, like installing anti-virus software on your PC in case a website uses a vulnerability in Internet Explorer to try and infect your computer with a virus. But Kaspersky doesn't make anything for cars.

This discussion has been archived. No new comments can be posted.

Bug Bounties Don't Help If Bugs Never Run Out

Comments Filter:
  • Bennett Haselton (Score:5, Insightful)

    by Laxori666 (748529) on Friday April 18, 2014 @11:44AM (#46787851) Homepage
    Bennett Bennett Bennett Bennett Bennett Bennett! I Bennett love Bennett Bennett! Nothing Bennett is Bennett more Bennett entertaining Bennett than Bennett reading Bennett what Bennett a Bennett person Bennett which Bennett I Bennett have Bennett no Bennett idea Bennett who Bennett they Bennett are Bennett has Bennett to Bennett say!
  • by kruach aum (1934852) on Friday April 18, 2014 @11:46AM (#46787873)

    Why do words, suddenly appear
    Every time, Bennett's here?
    Just like me
    you long to be
    free from this

    • It used to be that CmdrTaco or one of the others on the slashdot staff would occassionally post an article, but in general, the standard procedure would be that someone would write something on some other website, and then Slashdot would link to them.

      And sometimes, they'd link to one blog over and over again so often that were just rehashes of press releases (eg, coondoggie & Roland Piquepaille) rather than containing any original information or commentary, and they crowd out actual good articles on the

      • by Anonymous Coward on Friday April 18, 2014 @12:18PM (#46788165)

        But you don't understand. Bennett discovered DIMINISHING RETURNS.

        People need to know.

        NEED. To. Know.

  • You can't ever win a race with no finish line. Even if you maintain a constantly-increasing lead, your opponent will still eventually cover the same ground you do, so why even bother running?
    • by Oo.et.oO (6530)

      i understand that you think you are using a metaphor (even if it is in fact a simile)
      but either way it's false. in a race, you either finish or you don't. in software it's an on going process with (hopefully, but rarely) increasing quality and functionality.
      small battles can and are won.
      say you have 10,000,000,000 bugs in the system as a evidence.
      researchers find and patch 1,000,000,000
      is your system more or less likely to have an exploit found?

    • Re:Metaphor (Score:5, Insightful)

      by lgw (121541) on Friday April 18, 2014 @01:20PM (#46788753) Journal

      The notion that you can't have code without these flaws (buffer overruns, dangling pointers, etc) is just asinine. I've worked on significant codebases without any such flaws. You just have to adopt a programming style that doesn't rely on being mistake-free to avoid the issues.

      Want to end the danger of buffer overruns? Stop using types where it's even possible.

      Want to end the danger of dangling pointers? Managed code doesn't do anything to solve this problem, and is often the worst offender since coders often stop thinking about how memory is recycled, and well-formed objects can hang around in memory for quite some time waiting on the garbage man. So you have to write code where every time you use an object you check that it hasn't been freed, and importantly hasn't been freed and then re-used for the same object! (That happens on purpose in appliance code, where slab allocation is common.)

      Heck, for embedded code I simply wouldn't use dynamic allocation at all. All objects created at boot, nothing malloced, nothing freed. Everything fixed sized and only written to with macros that ensure no overruns. I wrote code that way for 5 years - we didn't even use a stack, which is just one more thing that can overflow. That style is too costly for most work, but it's possible, and for life-safety applications it's irresponsible to cheap out.

      • by rabtech (223758)

        While you are technically correct, the reality is that the most serious security vulnerabilities are almost all directly related to buffer overruns (on read or write), allowing an attacker to read or write arbitrary memory. Everything else is a second-class citizen by comparison; denying service by causing Apache to repeatedly crash is far lower priority than compromising all traffic and stealing credentials.

        So when we look at that class of serious problems, we find that managed memory languages completely

  • Bennett's Ego (Score:5, Insightful)

    by Anonymous Coward on Friday April 18, 2014 @11:50AM (#46787907)

    " I was an early advocate of companies offering cash prizes to researchers who found security holes in their products, so that the vulnerabilities can be fixed before the bad guys exploited them. I still believe that prize programs can make a product safer under certain conditions. But I had naively overlooked that under an alternate set of assumptions, you might find that not only do cash prizes not make the product any safer, but that nothing makes the product any safer — you might as well not bother fixing certain security holes at all, whether they were found through a prize program or not."

    Is the whole premise of this article Bennett having a conversation with himself, talking about his previous points that no one also cared about? I understand slashdot is trying to start doing op-eds by having this guy write. But everything he writes is this long-winded, blowhard, arrogant, ego-massaging nonsense that no one but him cares about. Here he's writing about his previous writings and how his thoughts have changed..in a poorly-written article with no sense of a conclusion..just rambling.

    Bennett is also not an information security expert ..he's just a blowhard..can we have someone really involved in information security, like Bruce Schneier, write articles for Slashdot instead of this nonsense?

  • By this logic... (Score:2, Insightful)

    ... we shouldn't attempt to arrest or prosecute criminals because there is always another one right behind the first?

    You should be ashamed of your apathy.

    • There aren't infinitely many criminals; crime rates are lower than they would be if we didn't arrest or prosecute criminals, because the population of criminals is finite and in fact small enough that our policing and sentencing policies can make a dent in it. (If there really were infinitely many criminals, then indeed it would be pointless to arrest or prosecute them, but there aren't.)
      • by Calavar (1587721)

        Even ignoring the ridiculous jumps and assumptions in your reasoning, your logic is absurdly inconsistent and contradictory. At any given moment, the amount of criminals is finite just as the number of bugs is finite. But it seems that you are not talking about a given point in time. Over an infinite period of time, criminals are also infinite because for ever X new births, some percentage of those people are pretty much guaranteed to become criminals. And every arrest has the potential of creating a new cr

        • by Calavar (1587721)
          Car analogy: Cars will break down an average of one time for every X days of use, so if you have a car for an infinite period of time, it will break down an infinite number of times. Does this mean that you should never take it to the mechanic? Absolutely not. You take it to the mechanic as quickly as possible so that you can minimize the number of days that your car is unusable and maximize the number of days that it is usable.
        • I'm talking about a large number of vulnerabilities that exist in parallel at a given point in time, not ones that exist in series where fixing one vulnerability introduces a new one.

          If a large number of vulnerabilities that can be found for $5K, then if you spend $5K of your own effort finding one such vulnerability so that you can fix it, the probability approaches zero that the attacker is spending their effort finding the same vulnerability.
          • by Calavar (1587721)
            Then that is simply a false assumption. If you have a finite amount of code, there can only be a finite number of bugs in it. If I were to write a "hello, world" program and then pay $500k for each bug report, would I uncover an infinite number of bugs? What about /bin/true or /bin/false or /bin/cat?
            • I said in the article, I didn't mean the number of independent bugs that could be found for (say) $10K worth of effort was literally infinite, only that you wouldn't come close to running out, in the time horizon before the software becomes obsolete.

              Again, do you think Apache could ever, in practice, reach a state where you couldn't find one more vulnerability in it for $10 million worth of effort? I would say, probably not. That's probably true for some much lower dollar value as well.
              • by Calavar (1587721)

                Okay, I guess I misunderstood parts of your post, but I still see some issues.

                First, you're assuming that the only consideration for people that find security vulnerabilities is money, so that if the potential illicit earnings from exploiting the bug are greater than the bounty, they will exploit the bug. This is definitely not true in practice. Some people just want to do good things. And even for people with no conscience whatsoever, they have to deal with the fact that doing something puts you into a hig

                • Congratulations, you're the first person who called me out for saying "infinite number of bugs", where I replied and said "I didn't say literally infinite, just big," and you actually got the point and moved forward :)

                  Okay, I guess I misunderstood parts of your post, but I still see some issues.

                  First, you're assuming that the only consideration for people that find security vulnerabilities is money, so that if the potential illicit earnings from exploiting the bug are greater than the bounty, they will exploit the bug. This is definitely not true in practice. Some people just want to do good things. And even for people with no conscience whatsoever, they have to deal with the fact that doing something puts you into a high stress defensive stance where you constantly have to cover your tracks. Most people wouldn't want that kind of lifestyle.

                  Yes, that's true -- so that introduces a fudge factor into the amount of the bounty, since it doesn't have to be quite as high as the black market value. It can be less, since most people would prefer dealing with the software manufacturer.

                  Second, you're assuming that the number of bugs found increases linearly with the dollar amount of bug bounties, but my gut instinct is that it is an asymptotic function. Increased bug bounties offer diminishing returns because after a certain point the limiting factor becomes the fact that bugs are really darn hard to find. (Case in point, OpenSSL. Every major tech company uses OpenSSL and several have conducted regular audits of it. Even with all that effort, no one was able to uncover the Heartbleed bug until earlier this year.) So even if Microsoft were to offer $10 million per bug, I don't think they would start finding more bugs than they could fix.

                  I don't think my conclusion depends on the assumption

    • No, we weigh the cost of prosecuting a specific crime against the cost of not prosecuting it, and let some crimes slide.

      So we spend a lot more time and effort prosecuting a murder than a jaywalker. Because it's worth more to stop the murderer.

      (And when this gets out of whack, we have problems. Red light cameras, GPS devices on cars, and such are reducing the cost of prosecuting some crimes, and that is causing social problems as we start to prosecute crimes that we didn't before. A lot of the complaints

  • If you start with the assumption that you can't make secure software, then you shouldn't make any software at all.

    • by mlts (1038732) on Friday April 18, 2014 @11:57AM (#46787989)

      People talk about bug free code. It is a matter of won't, not a matter of can't.

      Sometimes, there are products out there which can be considered "finished". Done as in no extra features needed, and there are no bugs to be found. Simple utilities like /usr/bin/yes come to mind. More complex utilities can be honed to a reasonable degree of functionality (busybox comes to mind.)

      The problem isn't the fact that secure or bug free software can't be made. It is that the procedures and processes to do this require resources, and most of the computer industry runs on the "it builds, ship it!" motto [1]. Unfortunately, with how the industry works, if a firm does do the policy of "we will ship it when we are ready", a competitor releasing an early beta of a similar utility will win the race/contracts. So, it is a race to the bottom.

      [1]: The exception to this rule being malware, which is probably the most bug-free code written anywhere these days. It is lean, robust, does what it is purposed to do, and is constantly updated without a fuss.

      • by RabidReindeer (2625839) on Friday April 18, 2014 @12:31PM (#46788279)

        People talk about bug free code. It is a matter of won't, not a matter of can't.

        Sometimes, there are products out there which can be considered "finished". Done as in no extra features needed, and there are no bugs to be found. Simple utilities like /usr/bin/yes come to mind. More complex utilities can be honed to a reasonable degree of functionality (busybox comes to mind.)

        The problem isn't the fact that secure or bug free software can't be made. It is that the procedures and processes to do this require resources, and most of the computer industry runs on the "it builds, ship it!" motto [1]. Unfortunately, with how the industry works, if a firm does do the policy of "we will ship it when we are ready", a competitor releasing an early beta of a similar utility will win the race/contracts. So, it is a race to the bottom.

        [1]: The exception to this rule being malware, which is probably the most bug-free code written anywhere these days. It is lean, robust, does what it is purposed to do, and is constantly updated without a fuss.

        Once upon a time, I read somewhere (Yourdon, possibly) that the number of bugs in a software product tends to remain constant once the product has reached stability. The number for IBM's OS/MVS mainframe operating system was somewhere in the vicinity of 10,000!

        It's been likened to pressing on a balloon where when you squeeze one bump in, another pops out, because the process of fixing bugs itself introduces new bugs.

        And OS/MVS is about the most critical software you could put on a mainframe. You can't just Ctrl-Alt-Delete a System/370. Or power it off and back on again. Mainframes are expensive, and expected to work virtually continually. Mainframe developers were expensive as well, since after a million dollars or so of hardware and software, paying programmers handsome salaries wasn't as big an issue back then. Plus there was no offshore race to the bottom where price trumped quality at the time. In fact, there wasn't even "perma-temping" yet.

        Still, with all those resources on such an important product, they could only hold the bug count constant, not drive it down to zero.

        Actually speaking of OS/MVS, there's a program (IEFBR14) whose sole purpose in life is to do nothing. There have been about 6 versions of this program so far, and several of them were bug fixes. More recently, it had to be upgraded to work properly on 64-bit architecture, but some of the bugs were hardware-independent.

    • by SourceFrog (627014) on Friday April 18, 2014 @12:02PM (#46788021)
      It's retarded to assume that you can't make a product secure; there aren't "infinite" bugs, there are obviously a finite number of bugs in any piece of software, and anyone who thinks otherwise either has some strange mental illness or doesn't understand software. But the reason bug bounties mostly don't work has nothing to do with the author's wiffle-waffle, it's just simple math and cost of labor. If I have the level of skills required to find security holes in a large piece of software like Windows or IE, chances are I can sell my labor at a minimum of $50/hour. To find a bug, I'm likely going to have to spend several days or weeks at it. If there's a $1000 bounty, that means I can spend at most 20 hours on the problem until I am literally losing money in opportunity costs. And hackers have to pay their mortgages and bills too. It's kind of insulting to think that an experienced security expert is going to labor away to find your bugs for you at well below market rates for that work if you had to pay someone to do it, as if a dog getting excited about a small treat, it's patronizing and insulting. If it would cost a company like MS $100,000/annum to have a security expert on their dev team to find those same bugs, then any 'bounty' has to START at well above those effective hourly rates.
      • Yeah, I think $1,000 is way too low, I just used it as a sample number.

        I think all that matters is that the dollar number matches the black-market value. Then it doesn't matter whether most people would find the effective hourly rate "insulting"; all that matters is that anybody who does find an exploit will turn it in to the company rather than selling it on the black market or exploiting it themselves.
        • by Wycliffe (116160)

          But what is the "black market rate" for 1 million credit card numbers? $20 a piece? What is the cost to the company if they lose 1 million
          credit cards? This is a job for the bean counters but in some cases it might be worth it not to pay for the bug if you think it'll cost you less
          than $20 million in mitigation of reputation,etc.. In other cases, it might be worth alot more than $20 million if for instance a lose of 1 million
          credit cards causes Bank of America to lose $100 million of business. I think

        • What about scarcity? Wouldn't scarcity of exploits on the black market just drive the prices up eventually putting the price over the infinite bug price?

          Although I agree that if there is enough money involved someone will find a way even if it is an indirect exploit to an otherwise solid application.

          • I believe the distinction is that scarcity can drive up the price of something but usually not it's value (to you). The price is where the supply and demand curves meet; you buy the good if it value to you is greater than the market price, and if its value to you is greater than the market price, that's just pure benefit to you (the "consumer surplus").

            So, you place a certain amount of value on being able to break into Apache webservers. If existing vulnerabilities get found and fixed, that will, indeed
        • Then it doesn't matter whether most people would find the effective hourly rate "insulting"; all that matters is that anybody who does find an exploit will turn it in to the company rather than selling it on the black market or exploiting it themselves.

          You're assuming they can only choose one. What is there to prevent someone from exploiting the bug themselves for a while, selling it on the black market (to a discrete buyer), and still eventually turning it in to collect the bounty?

          • Good point, someone else mentioned this and I'll just copy and paste what I wrote here:

            Right, I forgot to mention something: To prevent double-use like this, a company should say that you don't get paid until they've fixed the bug and issued a patch for it in their software, all without the exploit ever being spotted in the wild. (If someone else finds your vulnerability and exploits it in the wild, that's just bad luck. So to incentivize researchers, Microsoft might have to increase the prize money propo
      • by punkr0x (945364)
        I think the purpose of "bug bounties" is to encourage researchers to document and report bugs. It's not like anyone is going to make a full time job out of collecting the reward money, but if you happen across a potential security hole, it's worth your time to reproduce and report it.
    • We start with the assumption that the vast majority of the market isn't willing to pay a company substantially more to ship a formal proof of a software product's security along with the product. I'm interested in your bright ideas for making such a formal proof economical.
  • by NiteMair (309303) on Friday April 18, 2014 @11:56AM (#46787981)

    Paying people to find bugs and report them responsibly does give those people an incentive to not do something worse with them.

    In a way, this economy takes possible would-be black hats and turns them into white hats. I suspect there are far fewer people capable of finding every last exploit than there are exploits, so if we keep those people busy and paid doing what they do best, at least they won't be doing something more nefarious.

    • Paying people to find bugs and report them responsibly does give those people an incentive to not do something worse with them.

      Right, I forgot to mention something: To prevent double-use like this, a company should say that you don't get paid until they've fixed the bug and issued a patch for it in their software, all without the exploit ever being spotted in the wild. (If someone else finds your vulnerability and exploits it in the wild, that's just bad luck. So to incentivize researchers, Microsoft might have to increase the prize money proportionally, to make up for the fact that sometimes people won't get paid because their e

      • by jc42 (318812)

        To prevent double-use like this, a company should say that you don't get paid until they've fixed the bug and issued a patch for it in their software, all without the exploit ever being spotted in the wild.

        One problem with this is that there's already a documented history of companies rejecting bug reports and not paying the bounty, and then some time later include a fix for it in their periodic updates. It's basically the same process that causes a company's "app store" to reject a submitted tool to do a particular job, and then a few months later releasing their own app that does the same thing.

        I know a good number of people who've been bitten by the latter, from both MS and Apple. In the case of a bug

        • Yes this would be a valid concern. So this is a reason why some people might not bother searching for vulnerabilities at all -- they don't want to sell them on the black market, and they don't trust the company to pay them.

          But fortunately I don't think that's fatal to the analysis because that just leaves the people left over who are willing to do the work to find vulns. All that matters is that they think the software manufacturer is more trustworthy and more likely to pay than the black-marketeers. T
  • Wrong (Score:5, Insightful)

    by Stellian (673475) on Friday April 18, 2014 @11:58AM (#46788001)

    There is no such thing as a "black market value" of a security vulnerability. Both the demand and supply have curves. I.E there are security researchers who would demand say 1 million bucks before selling the bug to the CIA (because they view that action as unethical, illegal and risky careerwise) while they would gladly accept 10.000$ in a responsible disclosure offer. Other color hats would go to the highest bidder. Similarly, there are large transaction costs and information asymmetries, it's not necessarily true that the demand and supply meet or that they can trust each other. A spy agency might rather develop in house (at a much larger cost) then shop around and rise suspicion.

    In short, offering a non-trivial sum of money will always increase the costs of the average attacker and might completely shut off the low impact attacks like spam zombification, email harvesting etc., the developers of which can't invest millions in an exploit but would gladly use the free zero day+exploit just made public.

  • Every bug fixed raises the bar slightly. Although I suppose if you're pretty sure there are infinitely many security holes in your code that are all roughly equally easy to find then you shouldn't bother fixing them - you should get another job.
  • tldr (Score:5, Insightful)

    by Zero__Kelvin (151819) on Friday April 18, 2014 @12:05PM (#46788049) Homepage
    I did read far enough to realize that this person is an idiot. We need only look at the heartbleed bug. If a bounty was offered and resulted in a fix earlier the number of stolen keys would be less, but that is almost besides the point. Once closed they might find another bug, but the likelihood that it will leak private keys is extremely low. To use a car analogy, every car has problems. This is essentially like claiming that fixing the exploding gas tanks in a Pinto is of no use, because the car will still have other issues. Seriously?
    • The analysis only applies to similar classes of vulnerabilities. If you find a remote root exploit in Apache with $5,000 worth of effort, but it turns out there are an effectively infinite number of remote root exploits that can also be found with $5,000 worth of effort, then in fact it is pointless to fix it since that is well below the black-market value of such an exploit, and new ones will never stop being found. But it's irrelevant if there are other far less serious bugs.
      • by tomhath (637240)

        To paraphrase:

        IF you can easily find a serious security hole AND IF there are a very large number of other serious security holes AND IF there are also a very large number of less serious security holes, THEN there's no point in offering a bounty because the number of less serious security holes plus the number of more serious security holes is so large you'll never fix them all.

        Yes that's true. But it doesn't take a page long monolog to say it.

        However, IF your bounty turns up a security hole like Heartblee

        • Except this analysis is wrong and that's what happens if you try and take shortcuts. It doesn't matter whether there is a "very large number of serious security holes", it matters if there is a very large number of serious security holes that can be found for a cost which is less than the black-market value of the security hole.

          Yes, I'm sure the article could have been made shorter.
    • Re: (Score:2, Funny)

      by Anonymous Coward

      Yes, but to be honest, if your car has windscreen wipers that leave a smear, why worry about the random chance of explosion?

    • Re:tldr (Score:5, Funny)

      by Thruen (753567) on Friday April 18, 2014 @12:49PM (#46788431)

      I did read far enough to realize that this person is an idiot.

      So you only got to "Bennett Haselton writes:" then?

    • by Rich0 (548339)

      Yup. If you're just going to throw up your hands and say that bug-free software is impossible, why not just intentionally write software that doesn't work at all?

      My Linux kernel HAS to be broken. So, why not just edit the source and put an infinite loop at the entry point? The resulting black screen when I boot up must be just as useless as the OS I'm typing on right now, right?

    • by TubeSteak (669689)

      This is essentially like claiming that fixing the exploding gas tanks in a Pinto is of no use, because the car will still have other issues.

      No, it's like claiming that the Pinto is always going to have an exploding gas tank issue, even if you fix the current cause.

      Some cars (software) have so much going on that there will always be problems,
      unless you use a design process (coding language) that doesn't allow it to happen.
      Or do you really think that Microsoft products with millions of lines of code are someday going to be bug free?

  • ...it's the lack of accountability. The reason why Microsoft should take the cash is because they are not accountable for their bugs by contract. Finding a vulnerability costs them money, it does not make or save money. The only case that can be made for disclosing and fixing vulnerabilities is improved goodwill, but even that is tempered by the fact that what ever meager goodwill they gain by fixing the bug is probably cancelled by the loss in goodwill from having the bug in the first place.
  • Like so many others, my first code was:

    10 PRINT "HELLO WORLD"

    We started out with some basic operations and grew from there. Unfortunately most people kept what they liked and discarded the rest. Things like data and input validation are seen as a waste of time by so many. Strings and other data which get passed to other processes in other languages (like SQL, or Windows image libraries) also warrant some inspection.

    The types of vulnerabilities we find most often happen because programmers are neglecting

  • by SecurityGuy (217807) on Friday April 18, 2014 @12:14PM (#46788131)

    ...the notion that if you can't make software bug free, you may as well not bother is just stupid on a scale that's hard to comprehend. I skimmed as much of that article I could stomach, but I'm done.

    If we can't make cars crash proof, we may as well not make them safer.
    If we can't make people immortal, we may as well stop advancing medicine.

    You know what? If you can't find perfect stories, you may as well stop posting junk like this.

  • I'm gonna have to stop you right there, because your entire premise is retarded. If someone finds a bug in your software, and you don't bother to fix it, you are intentionally keeping the software less secure than it could be. That should be criminal, but I'd be satisfied with Ben 10 not being allowed to have a blog on slashdot anymore.
    • My point is that if there are (effectively) infinitely many bugs below the black-market value threshold, then the software isn't any less secure because you didn't fix a bug -- because you haven't changed the amount of effort it would take for the attacker to find their next vulnerability.
      • My point is that if there are (effectively) infinitely many bugs...

        No need to read any further because that is an incorrect assumption.

        There cannot be an infinite number of bugs (effectively or otherwise) because there is not an infinite about of code NOR an infinite number of ways to run the finite amount of code.

        From TFA:

        (He confirmed to me afterwards that in his estimation, once the manufacturer had fixed that vulnerability, he figured his same team could have found another one with the same amount of ef

        • Do you really believe that if you offered a $10 million prize to anyone who could find a vulnerability in the Apache web server, that you would reach the point where people weren't finding and reporting new ones -- in the time horizon before that version of the software becomes obsolete and the whole question becomes moot anyway?
          • by khasim (1285)

            Do you really believe that if you offered a $10 million prize to anyone who could find a vulnerability in the Apache web server, that you would reach the point where people weren't finding and reporting new ones...

            From your inclusion of "really believe" I'd say that your question was rhetorical.

            And wrong.

            At $10 million per buffer overflow? Yes. There would be a finite number of buffer overflows that would be found and fixed.

            At $10 million per X category of bug? Yes. There would be a finite number X's that w

  • by mbone (558574)

    I don't think he understands how security works.

  • Not true for software that was written properly, reviewed, unit tested and system tested.
  • by eyepeepackets (33477) on Friday April 18, 2014 @12:23PM (#46788197)

    Why not a security compiler? Seems some clever, creative hackers could work up something which would take raw code, subject it to some scrutiny and give output/feedback. Perhaps even a security switch to the standard compilers or even a security test suite. Shouldn't be that hard to do.

    • by swillden (191260)

      Why not a security compiler? Seems some clever, creative hackers could work up something which would take raw code, subject it to some scrutiny and give output/feedback. Perhaps even a security switch to the standard compilers or even a security test suite. Shouldn't be that hard to do.

      Shouldn't be too hard... in the sense that solving the Halting Problem shouldn't be too difficult. I conjecture that with an appropriate set of assumptions it's possible to use Rice's Theorem to prove that security analysis is equivalent to the Halting Problem.

      Of course, static analysis can catch some vulnerabilities, and can highlight potential vulnerabilities. That's what Coverity does. But I don't think any mechanical process can defeat a creative attacker.

  • by Opportunist (166417) on Friday April 18, 2014 @12:40PM (#46788345)

    First, bugs in a given program are not infinite in number. By definition. Because the code itself is finite. Finite code cannot have infinite bugs. Also, due to the nature of code and how it is created, patching one bug usually also takes care of many others. If you have a buffer overflow problem in your input routine, you need only patch it once, in the routine. Not everywhere that routine is being called.

    I have spent a few years (closer to decades now) in IT security with a strong focus on code security. In my experience, the effort necessary to find bugs is not linear. Unless the code changes, bug hunting becomes increasingly time consuming. It would be interesting to actually do an analysis of it in depth, but from a gut feeling I would say it's closer to a logarithmic curve. You find a lot of security issues early in development (you have a lot of quick wins easily), issues that can easily even be found in a static analysis (like the mentioned overflow bugs, like unsanitized SQL input and the like), whereas it takes increasingly more time to hunt down elusive security bugs that rely on timing issues or race conditions, especially when interacting with specific other software.

    Following this I cannot agree that you cannot "buy away" your bug problems. A sensible approach (ok, I call it sensible 'cause it's mine) is to get the static/easy bugs done in house (good devs can and will actually avoid them altogether), then hire a security analyst or two and THEN offer bug hunting rewards. You will usually only get a few to deal with before it gets quiet.

    Exploiting bugs follow the same rules that the rest of the market follows: Finding the bug and developing an exploit for it has to be cheaper than what you hope to reap from exploiting it. If you now offer a reward that's level with the expected gain (adjusted by considerations like the legality of reporting vs. using it and the fact that you needn't actually develop the exploit), you will find someone to squeal. Because there's one more thing working in your favor: Only the first one to squeal gets the money, and unless you know about a bug that I don't know about, chances are that I have a patch done and rolled out before you got your exploit deployed. Your interest to tell me is proportional to how quickly I react to knowing about it. Because the smaller I can make the window in which you can use the bug, the smaller your window gets to make money with the exploit, and the more interesting my offer to pay you to report the bug gets.

    • First, bugs in a given program are not infinite in number. By definition. Because the code itself is finite. Finite code cannot have infinite bugs.

      I agree... I did wrote, "Obviously the amount of vulnerabilities is not really infinite — you can only do finitely many things to a product in a finite amount of time, after all — but suppose it's so close to infinite as to make no difference, because the manufacturer would never be able to fix all the vulnerabilities that could be found for that amount of effort."

      Also, due to the nature of code and how it is created, patching one bug usually also takes care of many others. If you have a buffer overflow problem in your input routine, you need only patch it once, in the routine. Not everywhere that routine is being called.

      Right, I also said, "I'm hand-waving over some details here, such as the disputes over whether two different bugs are really conside

  • In other news, there is no point in cleaning your house because it will just get dirty again later.
  • Bug bounties don't always involve bugs. A lot of times it is paying someone to back port software. For example software x version 1.5 is available for and popular on... lets say an Ubuntu 12.04 based system. Version 2.0 comes out with a host of cool new features, except that it is only available for Ubuntu 13.10 based systems and the maintainers are not going to port it to 12.04. So, within the same frame work of a bug bounty, community members pool money and pay someone $300 to back port the software. I se
  • We should stop looking for bugs because we can never find them all. Maybe we should stop prosecuting criminals because we can't seem to stop finding more. There will always be murderers, so let's make killing legal.

  • This analysis is based on an erroneous assumption which is derived from an inductive fallacy. Specifically, the author assumes that because one researcher who found one bug believes he could have found a second for roughly the same level of effort means that the researcher believes this process could be repeated indefinitely. I'm certain that if Kohno were asked he would deny the validity of this assumption. I'm sure he would say that his team could find a handful of similar bugs for similar level of effort

  • First, he assumed that given x effort, you could find bu #1. That is a reasonable expectation, given the state of programming today. Bugs, while not infinite, are in fact so numerous so that the amount of time it takes to find them all exceeds the project life of software.

    Then he assumed that given y effort you could then find bug #2. Again a reasonable assumption.

    Third assumption, that x=y. This is FALSE. For that assumption to be true, then bugs are being found randomly, not by effort. The truth

  • Security is not binary. Security is not absolute. There is ALWAYS residual risk. There is no such thing as invulnerability or immortality. Everything can be taken down. Security is not an end state. It is an ongoing process. If you do not continually improve the security of software, by addressing known vulnerabilities, performing a sane risk assessment, identifying threats, and doing what you can to mitigate them, you will regret it. The notion that implementing fixes is pointless because there will
  • If the bounty amount were sufficiently large, i.e. larger than the amount of net profit a black hat could hope to gain by finding and exploiting security a given defect, couldn't a company create a scenario where even a black hat (acting rationally in order to maximize his profit, which is often not going to be the case) would be motivated to report it and claim the bounty rather than exploiting it?

    Now, in theory, if there are truly infinitely many such flaws to be found and subsequent ones aren't any har
  • The problem is C. Programs in all the languages that understand array size, (Pascal, Modula, Ada, Go, Erlang, Eiffel, Haskell, and all the scripting languages) don't have buffer overflow problems.

    It's not an overhead problem. That was solved decades ago; compilers can optimize out most subscript checks within inner loops.

    I've proposed a way to retrofit array size info to C, [animats.com] but it's a big change to sell. There are many C programmers who think they're so good they don't need subscript checks. Experienc

  • If we take a less-than-good-enough-quality product and iteratively inspect and rework/repair each defect, we will produce a good-enough product. Intuition seems to suggest that this *should* work! Can't you polish a rough piece of metal until it shines? Heck, mythbusters proved you actually can polish a terd.

    The manufacturing industry figured out a long time ago that you can't inspect in quailty. Your process has to produce a product-that-meets-customer-requirements, and if it doesn't you have to fix yo

  • I too have worked on projects with seemingly infinite bugs. I concluded that feeling just meant a big (BIG) chunk of code (perhaps the entire project) should be discarded and rewritten from scratch. Not, of course, that the company would ever agree to that...

"Right now I feel that I've got my feet on the ground as far as my head is concerned." -- Baseball pitcher Bo Belinsky

Working...