Slashdot Mirror
Bug Bounties Don't Help If Bugs Never Run Out
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.
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!
Why do words, suddenly appear
Every time, Bennett's here?
Just like me
you long to be
free from this
They're like the small kitchen cockroaches in suburbia. You never can get rid of them, so all you can do is mitigate periodically because over time they just repopulate from the outside in the wild (a.k.a. the neighbor's yard) which can be likened to "the cloud". (I use the RAID smoke, not the sticky spray.)
Tracy Johnson
Old fashioned text games hosted below:
http://empire.openmpe.com/
BT
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?
You do not have a moral or legal right to do absolutely anything you want.
" 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?
The value is a drop in the bucket for most companies that are widespread enough to need to do this. It's a lot better than say, going bankrupt because nobody trusts your product anymore. Even if you have to do it forever.
You should be ashamed of your apathy.
Which has more power: the hammer, or the anvil?
If you start with the assumption that you can't make secure software, then you shouldn't make any software at all.
set softtabstop=4 shiftwidth=4 expandtab nocp worlddomination
What a waste of time.
Fuck Ajit Pai
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.
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.
Content!
probably not.
pagerank algo encourages referencing one's previous posts.
algo changes us.
-s
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 topic. ... but what is Bennett's link to the site? Obviously, it's stronger than coondoggies Network World spamming, as he's linking in articles rather than directly posting them.
It seems like Bennett might have some tech cred, and may specifically have experience in this particular area ... but he posts on such a wide area of ... I'd say expertise, but some of it's poorly informed crap.
It almost seems like his submissions are trolling from the slashdot 'editors'.
Build it, and they will come^Hplain.
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.
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?
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
Make software programming an actual profession like electrical engineering. Because right now it looks more like a bunch of overgrown children moving pictures around on a screen.
...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 to pay attention to some of these very basic things. Others are more complex, but if these basic issues are still going on, then it's hard to see programmers as generally professional whether they are commercial or open source writers.
It may come as a surprise to some people, but the mistakes made in coding these days are increasingly critical in nature as civilization is increasingly reliant on what is being written and run out there. Much scrutiny and soul searching should be done. (It won't happen until some really bad things happen and frankly, the truly bad things are too much of an advantage to alphabet agencies so we won't hear a push for this from government in case anyone was waiting for it.)
...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.
Huh?
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.
I don't think he understands how security works.
Not true for software that was written properly, reviewed, unit tested and system tested.
Excuse me, but please get off my Pennisetum Clandestinum, eh!
If one makes the assumption that regardless of the infinite bug threshold, the security researchers are simultaneously both the black and white hats and therefore looking for and finding the bugs. The purpose of the prize is not to solicit the search for bugs but to become the purchaser of the bugs which are going to be found in any event. Not offering prizes means that infinite stream of bugs goes to the black market, offering prizes means that stream of bugs goes to the vendor.
What on earth makes someone assume there are two distinct groups, black and white who will only sell to their own respective markets? There is one large group that consists of everyone who makes a living hunting for bugs and they will sell to whichever market is most desirable. The black and white hats simply designate which market bought a given vulnerability. There might be a tiny smattering who will only sell to the white market on principle but they would have disclosed without a prize. There are probably zero or nearly zero who would refuse to take the money of the vendor today even if they've always sold to the black market in the past.
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.
Everything in the Universe sucks: It's the law!
Haselton's analysis (for what it is) in this post assumes that, just because a Professor said he thought it might take "about the same amount of time" for his team to find another vulnerability, that ALL security vulnerability research carries a linear, or at least deterministic, cost (in terms of man-hours, whether those hours are paid or unpaid).
This is simply not true. The reasons are as follows:
(1) Security vulnerabilities are best described by the methods or mechanisms used to find and then exploit them. Although there are some security vulnerabilities (such as buffer overflows) that can be searched for using deterministic methods that are relatively fast and sometimes even automated, there are many classes of vulnerabilities where the time investment required is completely unpredictable -- anywhere from minutes to thousands of years, assuming you have world-class security researchers working on them full-time. Not only is it not deterministic, but we can't even put any kind of reasonable bound on the amount of time it would take for someone to deliberately (or accidentally) discover such vulnerabilities.
(2) There are security vulnerability types (a "type" is classified by a close similarity in the procedure used to detect and/or exploit the vulnerability) which are either very rarely known to anyone on the planet, or completely unknown as of today, and may not be found or described at all for many years to come. These types may bring with them completely arbitrary, but interesting properties. For example, a yet-to-be-revealed class of security vulnerabilities may be trivial to detect, but require advanced degrees in physics or mathematics to exploit. Another class may require resources such as a quantum computer just to detect them, a resource which is not widely available in 2014. Since we don't yet know what the characteristics of undiscovered security vulnerability types may be, we can't predict, or even estimate, what the cost of finding them might be. It's not impossible to conceive that quantum computers (that is, either using quantum computers as a tool in detecting vulnerabilities in digital computers, or vulnerabilities in quantum computers *themselves*) might expose entire new classes of vulnerabilities that are trivial to detect and exploit, and frighteningly severe.
The "economics" of security research (where I speak of economics in terms of the amount of human and/or computer resources have to be "spent" to find and exploit a particular vulnerability) are far, far too dynamic to start throwing around big round numbers and inequalities. That kind of reasoning only applies when a specific type of product has been found to have many vulnerabilities of the exact same type, and these vulnerabilities are being continuously found using the same techniques day by day (or however long it takes to find a new one). This parade of same-class vulnerabilities may continue for a while, but in general, once a manufacturer gets slapped in the face with 2 or 3 vulnerabilities of a particular class, the next patch or product release they introduce tends to completely close off that class of vulnerability, after which the cost of finding a new class of vulnerability rises to the level of "indeterminate, and unpredictable even in principle".
Take Android rooting for example. For a long time we were able to root Android devices rather trivially, using similar vulnerabilities such as symlink attacks and unchecked input vulnerabilities in privileged system processes. Now, both manufacturers and Google have wisened up to these types of vulnerabilities, and either the bloatware devs or the manufacturers are testing for these vulnerabilities before they release their OTAs. So far, the Motorola Droid Ultra's 4.4 firmware has not been rooted, despite the line having a fairly large user base and more than a month of exposure (several months by now, actually) and $1500+ root bounty. That's because the attackers are using "old, tried and true" exploit types, which are now largely obsolete.
Bennett,
I know life can seem like an endless rat race sometimes. It is difficult to refute that logic to a rational mind, but we are not simply rational minds. We love and lose and fix endless bugs, and we shouldn't just give up.
You should consider seeking help. I know... it will be from some git psych major, but it's possible they will put your mind at ease.
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.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
Because it's widely understood that if anyone competent _really_ wants to kill the President, they're going to do it.
As always, all IMO. Insert "I think" everywhere grammatically possible.
I agree with much of your analysis, but I think the conclusion you draw isn't the most interesting or useful one from the available data. The better, but related, line of reasoning goes like this:
1) The more security-critical your software is to the world (protecting more dollars, as in users multiplied by the value of the what the users lose when this software breaks), the higher the black-market value of finding a bug.
2) The more total bugs your software has (defect rate multiplied by LOC), the more it costs to fix a given fraction of the bugs via a bounty system (whether that fraction is half or all of the finite bug count).
3) A software company can only rationally afford a given total bug-bounty payout for a product before the entire product (money earned on making+selling the software minus bug bounty payouts) is a net loss and they might as well discontinue and withdraw the software from the market. This sets constraints on the maximum bounty the company can rationally offer, which we can then compare to the black market bug value.
4) Therefore, in approximately the same cases you state it's not worth offering a bug-bounty at all (because there will always be more bugs that are "worth it" on the black market), the best conclusion is that the company should not be selling the software to users *at all*, and users should not rationally be consuming this software, because it's a net loss for everyone involved (except the black hat hackers).
5) Therefore, in any case where your original analysis concludes that it's not in the rational best interest of a company to offer a bug bounty, it's *also* not in the best interests of the company or its users for the company to even be selling that software in the first place (or for the users to be using it). So the meta-meta-conclusion is that after an unbiased self-analysis, a rational and responsible company has two real options: offer a bug bounty that's high enough to increase security (given black-market value), or withdraw the product from the market. It's never rational to keep selling the software *and* not offer a decent bounty, or any bounty at all.
In other news, there is no point in cleaning your house because it will just get dirty again later.
If we pay the police to stop one person from punching Bennett in the nose for being a boob what have we accomplished, there are an infinite number of people who want to punch Bennett in the nose for being a boob and therefore trying to stop people from punching Bennett in the nose is an exercise in futility.
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.
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 see this sort of thing happen all the time and have personally benefited from it. I also see distro maintainers offer bounties to fix bugs for their own projects or bounties to back port features of their latest system to their previous version. Or is he only talking closed source style bounties? Overall the article is hard to follow logically and seems to have a very narrow view of the world of software in general and I admittedly did not finish it because of that.
Brought to you by Carl's Junior.
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 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."
In fact I agree with everything you said, it just sounds like you're reaching the same conclusion that I did. Once you're done with in-house bug finding, offer a prize close to the black market value of an exploit in the software. If there are finitely many bugs in that range -- as you said, "You will usually only get a few to deal with before it gets quiet" -- then the prize will sweep them up.
Perhaps I should have emphasized: You don't have to start your bug-fixing by offering a prize, you can find as many of them as possible in-house, and from outsiders who report the easy bugs for free. You could even save money by starting with a lower prize, and then ramping it up slowly. (However, this runs the risk that someone might find a valuable bug early on, but keep it secret waiting for the prize money to go up. If they do this, they run the risk that someone else will find the same bug and claim the prize money and then the original discoverer gets nothing. But somebody still might try this. So that's a downside of slowly increasing the prize money.) As long as you end by offering a prize proportional to the black-market value of the vulnerability.
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.
The Information Revolution will be fought on the command line.
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, but once the pool of low-hanging fruit bugs was exhausted, the cost and difficulty would rise.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
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 is x is ALWAYS less than y, because it takes skill and effort to find them.
Each successive bug is more and more difficult to find. However, it is an exponential chart. This means when just starting out, it APPEARS that x=y, but the further you go along, then Y starts being significantly greater than x.
This is a common problem, faced by mothers cleaning their house and by cops facing criminals. By the time they clean up one mess, a new one has popped up. But that does not mean you stop cleaning. Your efforts do mean something. The idea is to always be one step AHEAD of the mess, not behind it. That way you always end up with an acceptably dirty situation, rather than a virus infected/crime ridden area.
excitingthingstodo.blogspot.com
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 always be more vulnerabilities is wrong. Yes, there will always be vulnerabilities. Yes, security is a job that never ends. No, you can't ignore vulnerabilities once you know of them.
You see? You see? Your stupid minds! Stupid! Stupid!
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:
Then he was wrong as well.
There are a finite number of times that buffers are used in that code base. Therefore there are a finite number of times that buffers could be overflowed. If someone went through the code and checked each instance and ensured that an overflow situation was not possible then it would not be possible.
"Infinite" does not mean what you think it does.
Earth sized exoplanet found in Habitable Zone. Meanwhile, you get rambling garbage from borderline "Wired level of knowledge" sophists.
http://soylentnews.org/article.pl?sid=14/04/18/0324230
Seriously though, you guys keep Bennett. He's all yours.
This argument is nonsensical. It assumes that security is about money. Cash for vulnerabilities is a responsibility based on human impact, not a business decision based on money.
I wish. Granted, it has a lack of Haselton going for it, but I really tried to like it and couldn't. Seems to be most of the same clickbait crap that gets posted here - and often on a one or two day delay (and it's not like /. is on top of things to begin with). There was some particularly egregious trolling clickbait headline last month that just made me give up on it. Not that /. is any better in that regard, but if the new community isn't any better than the old, why go to the trouble of moving?
Thesis is essentially that fixing a bug doesn't increase security because the software still has an infinite number of bugs.
Obviously, this is false. A software package may have 6 security bugs. Fixing 3 of them reduces by 50% the chance that the bad guy will find one.
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 harder to find than the initial ones then a large enough bounty would bankrupt the company. But I have serious doubts at the presence of infinite (or even "practically infinite") security flaws that all require "about the same effort" to find. My suspicion is that the difficulty will increase the more flaws are found.
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, 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. Experience demonstrates they are wrong.
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 your process.
Oh, and the terd? It was shiny, but it still stank. And they don't last very long, anyhow.
"Reality is that which, when you stop believing in it, doesn't go away." - Philip K. Dick
The article is a lot of words for an over-simplification. It basically considers the trade-off of cost of one way of fixing bugs to the price a black-hat would pay for a found bug. There's so many things wrong with that.
For one thing, if I found an interesting vulnerability in some software, e.g. IE, I personally would not sell it to a blackhat for any amount of money.
So, the price for a blackhat to buy a bug from me approaches infinity, or a great deal more than a $1000 prize
I think most people are like me. They're not criminals and they won't have anything to do with criminals.
Secondly, the article only looks at one kind of cost - the reward paid or not.
Unfixed bugs cost money in terms of lost goodwill.
If that were not true, no one would use Firefox; we would all still be happily using IE 6.
Attacks can cost a great deal of money from scrambling to fix and/or apologizing to in various ways to victims.
Also, consider how much it would cost the company to pay its own developers to look for bugs in its own product.
How many team-hours could you get for $1,000 where you work. IS that even enough for one meeting?
You mean the same story that was on slashdot YESTERDAY: http://science.slashdot.org/st...
Proves my point below that soylent news is "yesterday's slashdot news today." Don't get me wrong, I wish it wasn't, but you can't sit there all smug and self-satisfied when your solution is in reality no better...
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...
Aside from the obvious ethical reason, I see two reasons more important than the $1,000 to go "white hat" rather than "black hat".
When a potential employer Googles my name, I want them to find my name on CVEs, Github commits, etc. - demonstrable proof that I do in fact find and fix real-world issues. I'm working on that. Right now, I'd have to point out my contributions, they aren't easily found via Google. For that, having a company or other organization publicly acknowledge my work is much more valuable than $1,000, if it helps me land a great job.
On the other hand, selling it on the black market could put me in federal prison. If the god guys offer me $1,000 plus a reputation boost, while the bad guys offer me $5,000 plus a possible prison sentence, I think I'll take the good guys' offer. That $1,000 could, in some cases, be enough to pay someone's past-due rent so they don't feel they have HAVE to capitalize on it in a bad way.
The other scenario I see is that several times per year I notify a smaller company of some security hole I noticed in passing. I haven't thoroughly probed it, just noticed "gee, it throws an error on O'Doole, it's probably not escaping the input and therefore vulnerable to SQL injection". Sometimes I don't bother to track down the proper person to notify and go notify them. Sometimes, I send an email to the only readily available email address, customer service, and the $8 drone on the other end replies with a form letter wholly inappropriate to the situation, so they obviously don't understand what I told them. In those cases, I'll likely not spend much time trying to find another person at the company. If most companies paid even $100 for a bug bounty, that would make it worth my time to spend a few minutes finding their report form and use it. Heck, at $100 per SQL injection vulnerability I could make a good living finding and reporting those for six hours per day.
Why doesn't the developer and his/her company do a good job of reducing such bugs in the first place? How much time and money is wasted taking computers offline for updates, how many millions spent on admins patching systems? If the bugs were hard to avoid, I would understand. But c'mon, this is (criminal) laziness and greed, hiring incompetent developers (or paying competent developers the same salary as incompetent ones), and doing a rush job to release the software early to keep some artificial schedule (to save development cost money).
So in short, the developing company and their developers are personally responsible for many bugs and they should pay market price for their incompetence and not expect charity from strangers to do all the hard work finding the bugs.
I don't know what all that verbiage was actually about (game theory?), but I like "the infinite bug threshold" - I think Android has already slipped over the event horizon. This term deserves to be part of hacker jargon.
I see the problem here. You're expecting most Slashdot readers, many of whom are Linux zealots or FOSS extremists (opportunist is one such example), to read an entire article. They don't do that. They read up until the point they find something that pisses them off, then they post why they are right and you are wrong.
No. They understand and they are explaining to YOU where YOU are wrong.
And that is where you are wrong. YOU are claiming that a very specific HYPOTHETICAL situation is same as the general ACTUAL situation.
Your HYPOTHETICAL situation is 100% divorced from the ACTUAL situation.
In the ACTUAL situation there are a finite number of buffer overflow bugs in any specific program and those buffer overflow bugs can be found and fixed WITHOUT another buffer overflow bug appearing. And it is EASY to find the MAXIMUM number of buffer overflow bugs by searching the source code for every instance of a buffer being used.
Finite AND countable AND fixable.
No. They are pointing out that YOU have made that assumption even though YOU keep denying it.
Because once you admit that the number of buffer overflow bugs is finite AND countable then there exists a point where they can ALL be fixed. And you keep denying that that is possible.
This is the most illogical thing I've ever read.
The dude says: "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".
That's wrong. To have access to $1,000, Microsoft has to earn maybe $1,350 on account of the federal, state and local taxes. But that's not enough because they also need to pay their staff (and their office space), plus the lawyers and accountants who process quarterly for the earnings reports, plus banking fees, and lots of other stuff.
So paying a $1,000 bounty requires them to forfeit a $1,500 income, while getting a $1,000 cash payment means a $750 profit. Even if the bug is a big one (which rarely happens), what is going to happen? People flocking to OSX and Linux? If you ask the shareholders, taking the cash is a no-brainer.
This being said, I still don't understand why Microsoft bothers with IE. What do they have to gain? They should take a small chunk of their IE budget and fund Firefox.
lucm, indeed.
"Okay, there are not infinite bugs, but let's assume there are and make strong conclusions based the on concept of infinity..."
This guy is a fucking idiot. The VERY REASON that you don't find all the bugs in a complex piece of software is the diminishing returns on your effort to find bugs. There are a finite number of bugs, you offer the bounty and get the easiest ones found out. Then there are diminishing returns for finding additional bugs, so the payouts stop. To talk about finding bugs without acknowledging the diminishing returns on finding bugs is mindbogglingly dumb.
It is also worth noting it is not truly impossible to eliminate all bugs, it is just highly unlikely, and the efforts are constrained by the diminishing returns problem.
Democracy Now! - your daily, uncensored, corporate-free
Everything I've ever heard says that a lot of malware code is terrible, quality-wise.
The thing about malware is that the authors care less about the code quality. They rely (I think) upon feedback. Either it works or they don't get paid. However the code is frequently launched into cyberspace only to perform an immediate faceplant. So the authors patch it up and ship it out again, and again, and again.
It's very Darwinian and the frequent dev cycles look a little like Agile (ha!).
Eventually it works well enough for the purpose intended. But I don't believe that the authors really care about "quality" per se. You can have a garbage code base that still gets the job done.
How about I just call you numbnuts instead?
Alright firstly, your posts are not to a news aggregate what chicken burgers are to McDonalds, especially considering McD's has never been a "beef hamburger joint" or anything so limited. Your posts are not some small deviation from the usual, they're not even always particularly "nerdy" in nature. A more apt comparison would be if McDonalds started selling coffee tables, it's completely unrelated and not what anyone goes to McDonalds for. In fact, it's like Slashdot selling coffee tables, except I bet they'd gain more visitors than they drive away with that one. As for this being the direction Slashdot wants to go in, are you affiliated with Slashdot and can you speak officially to this? Otherwise, I think even you need to admit it's very far out of place from everything else Slashdot consists of and arguably does not belong.
I think it's clear from the responses you receive here that the worth of your posts is debated about as much as the topics themselves. You'd get as much interesting discussion were the topic, "Should Numbnuts be allowed to blog on Slashdot's front page?" Beyond that, you may find your individual reasoning steps hard to argue against, but the rest of us don't. That's not to say you're not smart enough, but you probably already know that it's far easier to pick apart an argument coming from someone else than see the holes in your own. I still don't see why your opinion deserves to be on Slashdot any more than any other fool's opinion.
Now here's an easy question to give me a straight answer to: What's the process you follow for submitting these? Are you just filling out the submission form like anyone else and for some mysterious reason the editors post it?
The safest code is that which is never run. That doesn't mean you want to go there.
But I don't think the competition of the official prize with the black market is relevant at all.
Right now a big proportion of exploits come from security researchers, partially because they're looking for exploits, but also because they do have a strong incentive to find and report vulnerabilities. I don't think a cash prize is going to change their calculation much.
The place a prize could make a difference is in ordinary developers. I suspect a lot of bugs are partially discovered multiple times before they're officially reported. Some developer is working with the software, notices some weird behaviour, but doesn't follow up because they lack the incentive. A cash prize increases the incentive and potentially turns some of those dev hunches into new bug reports.
The way the black market comes into play is the devs are competing against the black market. If the bug discovery rate goes up the price of zero-day exploits goes down (since they're shorter lasting) as does the incentive to discover them (since good devs are competing for the same bugs). So you can significantly impact the black hat market without approaching the black hat rate.
I stole this Sig
"Actually, given the size of the Slashdot audience, I'd wager anything that doesn't amount to mere gibberish will spark some discussion."
Your wager is correct, so I'm not taking it! : )
An easy way to show this is that if someone posts an attempt at a insightful/informative note in the comments, *especially early enough*, it does two things. The "discussion sparked" is directly trackable because the subsequent replies tend to carry that subject title X far down in the threaded format, stopping at the next "highest level node of the tree". Then yes while there are *other* ways, a good post tends to eventually get noticed by the mods and gets at least a couple +1's.
The other thing is if you get a good early start in the thread before the humorists show up, the whole thread becomes better because we don't care as much about those memes farther down after a story is X hours old with 180 comments.
My first Journal Entry ever, in 8 years! http://slashdot.org/journal/365947/aphelion-scifi-fantasy-horror-poetry-webzine
"Now here's an easy question to give me a straight answer to: What's the process you follow for submitting these? Are you just filling out the submission form like anyone else and for some mysterious reason the editors post it?"
Just sayin', I noticed you're trying to pin down the question we've all been wondering for years, but he'll keep wriggling around it. Clearly yes he is "affiliated" because there's whatever "infinitely" (to use his favorite synonym of Very Large) close to zero statistical random chance that the only blog posts are his. We just don't know the exact nature of the transactions involved.
Meanwhile in the context of this particular piece, he does seem to be making lots of mistakes. So maybe he thinks "what's the value to me to shake out my reasoning if the commenters will do it for me?" There's no downside for him because we all say our bit, he adds some unclear replies, then he gets to start all over the next week.
My first Journal Entry ever, in 8 years! http://slashdot.org/journal/365947/aphelion-scifi-fantasy-horror-poetry-webzine
If software were a closed system, you might be able to argue that the number of bugs is finite. But it's not.
For example, if you know what you are doing, you can write code that is immune from SQL injection attacks...today. But SQL will change, and it is possible that in the future, SQL will add a feature, or experience a change, that will introduce a bug into your software that will make it once again possible to inject SQL, using an entirely new approach.
Given the complexity of the interactions between various systems within the computer, and the software being designed, there really IS an infinite potential for bugs.
False premise.
There are not infinite bugs, as you followed up in a comment below. (#46788587). This portion of your premise was invalidated by your own comment.
False premise
The premise here is that there is a budget, and that someone is spending money to find a vulnerability. Sure you can argue economics and opportunity costs and time as measured by a wage. But the hackers finding these bugs are *NOT* thinking about this the way you do. You are apparently an economist of some sort, and you don't think like the people actually doing the things you write about.
Ivan sitting in a hut in Siberia may spend $10,000 per year on heating and food, making a $50k vulnerability worth 5 years of time. If he is more self sufficient, $50k could be worth nearly infinite time. But all he needs are 20 $500 vulnerabilities per year to keep himself afloat. Or 10 of your proposed $1000 bugs.
In fact, I could argue that Windows has infinite bugs, because even patches contain bugs and have to be re-patched. And new code comes out every 3 years, largely untested by white hats. If all the bugs are found, in every service pack and update, we just wait till the next version and look for all the new bugs.
Compare with this:
You did not say the same thing I said. You said infinite bugs, or effectively so. I am talking about a moving target, which you did not mention.l So I can't assume you meant a moving target.
The remainder of your text is basically argument ad nauseum based on either the infinite bug thesis, or economist theory like "spending an estimated $70,000 to find a vulnerability that is only worth $50,000".
Again, think of Ivan in the hut, who does not "spend" $70k. As an economist, it might hurt your head to think this way, but Ivan is having fun poking at the code. This is like a Sudoku or crossword puzzle, costing nothing. Opportunity costs? He is not giving anything up. He likes doing this, and people pay him when he gets something exploitable. It is his job, and he doesn't care how much he makes because he earns enough or more than his lifestyle requires.
Incorrect statement? Just the ones about infinite bugs. But incorrect premise, and incorrect application of theory are rampant. Lots of people seem to be trying to tell you this, but not finding the words. Describe the world as you see it from your ivory tower, but reality is far different.
> My point is that there is probably some dollar value at which the cost to find the next vuln would never increase beyond that -- in other words, the Apache web server could never reach a state at which you could not find a new vuln for less than $10 million.
And that's GUARANTEED to be wrong. We know for certain that after all vulnerabilities are found, spending $100,000,000,000,000,000 still won't find another one. We can reason that the last vulnerability may well be either a) very hard to find (not worth it) or b) fairly to find (in which case $1000 bounty is perfect.). We can guarantee that at some point infinite resources would be wasted, because there are no more findable vulnerabilities severe enough to be worth finding.
It is an interesting conceptual argument, although it ignores a couple a real-world points.
First, not all bugs are equal, in terms of exploitation opportunity, as he's glossing over; the vulnerability is only as valuable as what it can be exploited to allow access to, in monetary exploitation terms. A bug in something which cannot be exploited for any particular gain is next to worthless, in market terms.
Second, not all companies will pay for vulnerability information, because it's not just a value proposition, but also a risk and resources assessment. If nobody expects your software to be "secure", there's no point is spending too much money on software security; for example, nobody pays much attention to the software in cars (yet), so manufacturers have little financial incentive to make it secure. Moreover, if you don't have deep pockets, you're not going to pay for exploits, especially if you're struggling to simply produce features that potential customers want. In either of those scenarios, the value proposition for paying for exploits is inconsequential.
Most (by volume) software has an effectively unlimited amount of bugs, which nobody will pay for. That's the real world of software.
Ok, the envelope game. You can rework it to say the second envelope contains the next vulnerability in the queue of vulnerabilities. An empty queue is just as valid as a non-empty one, so if there are no further flaws then the envelope is empty. That way, all states are handled identically. What you REALLY want to do though is add a third envelope, also next item inquire, from QA. You do NOT know which envelope contains the most valuable prize but unless two bugs are found simultaneously (in which case you have bigger problems than game theory), you absolutely know two of the envelopes contain nothing remotely as valuable as the third. If no bugs are known at the time, or no more exist - essentially the same thing as you can't prove completeness and correctness at the same time, then the thousand dollars is the valuable one.
Monty Hall knows what is in two of the envelopes, but not what is in the third. Assuming simultaneous bug finds can be ignored, he can guess. Whichever envelope you choose, he will pick the least valuable envelope and show you that it is empty. Should you stick with your original choice or switch envelopes?
Clearly, this outcome will differ from the scenario in the original field manual. Unless you understand why it is different in outcome, you cannot evaluate a bounty program.
Now, onto the example of the car automotive software. Let us say that locating bugs is in constant time for the same effort. Sending the software architect on a one-way trip to Siberia is definitely step one. Proper encapsulation and modularization is utterly fundamental. Constant time means the First Law of Coding has been broken, a worse misdeed than breaking the First Law of Time and the First Law of Robotics on a first date. You simply can't produce enough similar bugs any other way.
It also means the architect broke the Second Law of Coding - ringfence vulnerable code and validate all inputs to it. By specifically isolating dangerous code in this way, a method widely used, you make misbehaviour essentially impossible. The dodgy code may be there but it can't get data outside the range for which it is safe.
Finally, it means the programmers failed to read the CERT Secure Coding guidelines, failed to test (unit and integrated!) correctly, likely didn't bother with static checkers, failed to enable compiler warning flags and basically failed to think. Thoughtlessness qualifies them for the Pitcairn Islands. One way.
With the Pitcairns now overrun by unemployed automotive software engineers, society there will collapse and Thunderdome v1.0a will be built! With a patchset to be released, fixing bugs in harnesses and weapons, in coming months.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Of course there is the threat that changes in a system will introduce new bugs, but these bugs are not under your control. And whether or not your underlying system changes is not entirely dependent on the system's maker, it also matters whether or not you deploy the new version.
Also, it is very, very rare that changes in an underlying system rip open a critical security hole, at least one that you didn't notice due to the change log info. Looking back I can't really remember an instance where such a thing happened to us. We had quite a few compatibility issues, which of course, due to the necessity of code change, bore the potential to introduce new security holes, but I don't remember any security issues with existing code due to version changes.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
Woohoo, I have a fan!
Too bad it only blows hot air.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
I see a lot of objections to the word "infinite" being bandied about.
Bugs are fixed by software developers. And software developers introduced the bugs, unwittingly, into the original code in the first place. Some of the bug-fixes will introduce further unforeseen vulnerabilities. So it's quite probable that the true number of vulnerabilities in a system fluctuates, increases at times, and may only reach zero after an infinite amount of time. The assumption that there is a set of vulnerabilities in a system and this set can be reduced to zero by systematically finding and fixing them all one-by-one is clearly overly simplistic. Add software upgrades into the mix, and I think it's safe to assume that all software is buggy all the time.
> "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?)"
Sure. Educate your users so that fewer of them allow themselves to be vulnerable to the bug. This doesn't work in all cases, but certainly some -- encourage your software users to use better network security, to avoid using their actual ID information, etc. If fewer of the software's users are valuable to the crackers because the users protect themselves, then the black market value of the vulnerability goes down. If my front door lock can be picked, I'm vulnerable -- but if I don't store my most valuable items in my house at all, the value of picking my lock goes down... maybe to the point where the cost-benefit ratio to the criminal makes my house a bad bet for a burglary.
Support a few technologists in Washington.
2) It makes me think about a topic I probably wouldn't have thought about.
3) The slashdot comment section assassination is hilarious. I don't think I've ever read the comments section of Bennett Haselton post and not laughed out loud to the point others around me want to know what I'm reading.
I feel bad for the guy (hopefully he doesn't read the comments on his article) and in a way I feel a little bad for getting enjoyment out of the misery of others.
If slashdot turns into only articles like this, I'm out, but 1 in 20 posts like this is a nice change of pace.
+1 entertaining to both sides!
Even if you get rid of all bugs, there will still be security holes. Fixing these security holes can potentially jeopardize the functionality of the software. For example, if you allow scripting in software, you introduce many difficult to fix security holes. If those security holes were fixed, the scripting will inevitability be less useful.
"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." Ah we are talking about Windows now eh?