> That said, I think the for argument for having a “national bug bounty” > is to make the choice for independent researchers competitive - do you > sell to [name a country], or do you sell to US-CERT? What if they’re > both paying the same price? What if by selling to US-CERT, you get a > byline on some website and retain the freedom to talk to whoever you > want about your bug? Then maybe if some random Geohot-alike stumbles > over a tcpip.sys 0day, they sell it to CERT instead.
Great podcast from NPR Planet Money on exactly a case like this one: http://www.npr.org/blogs/money/2015/01/09/376164768/episode-596-johnny-mnemonic-s-secret-door -Dan On Sun, Nov 23, 2014 at 5:05 PM, Dan Guido <[email protected]> wrote: > In reply to an older post: > https://lists.immunityinc.com/pipermail/dailydave/2014-October/000784.html > >> -- once coin-operated vuln finders won't share, the percentage of >> all attacks that are zero-day attacks must rise, and it has. > > Before I begin, I have issues with the premise of this argument. Is > there evidence that supports the claim that “zero day attacks have > been on the rise”? By what metric? Are there now more campaigns that > use 0day? Have more computers been hacked with 0day as compared to > click_me.scr in the last 5 years? In my experience, our industry finds > ~30 0day exploits in the wild per year (not counting web applications > where nearly everything is custom). Even if this number is 2x what it > was in 2009, it’s nothing but a drop in the bucket for the sum total > of all attacks. Then, of course, it may be the case that we are > modestly better at finding 0days now since most people are finally > aware that they should look. > >> In a May article in The Atlantic,[BS] Bruce Schneier asked a cogent >> first-principles question: Are vulnerabilities in software dense >> or sparse? If they are sparse, then every one you find and fix >> meaningfully lowers the number of avenues of attack that are extant. >> If they are dense, then finding and fixing one more is essentially >> irrelevant to security and a waste of the resources spent finding >> it. Six-take-away-one is a 15% improvement. Six-thousand-take- >> away-one has no detectable value. > > Bugs are not sparse or dense. The architecture of an application > determines the number of bugs present and, as a developer, you can > control this property. > > I think this may be obvious, but there is software on both sides of > sparse vs dense. On one hand, you have software sparsely populated by > bugs like vsftpd, openssh, and qmail. It's straightforward to see why: > the churn of new code is low and they are based on well-understood, > mostly static specifications. On the other hand, much of the code we > use is not developed that way and is densely populated with bugs as a > result. JavaScript interpreters, document readers, Rails, even some > kernels are so densely populated with bugs that additional individual > vulnerability disclosures have low incremental value. Software > companies strongly compete on the speed of their JavaScript > interpreter and sometimes rewrite them multiple times per year. The > number of bugs introduced likely matches the number of bugs fixed and > the overall density remains constant and high. > > Although, you don't have to take my word for it. We have empirical > systems that help us measure the difficulty of finding vulnerabilities > in software: bug bounties! Rather than think of bug bounties as a > means to an end, I think of them as a measurement of a current and > trending state. If you can purchase vulnerabilities in a given > software for $500 "off the street" and patch > 10 of them each monthly > patch cycle, then your software is probably dense with bugs. If you > find yourself in this state, then any additional vulnerability > purchases are mostly meaningless. You should invest in exploit > mitigations to stem the bleeding while you re-architect the software > properly. If you are successful, then you should see the minimum price > per vulnerability of a given type rise and the quantity acquired per > time period decrease. > >> sharing. If you are finding vulns for fun and fame, then the minute >> you find a good one you'll let everybody know just to prevent someone >> else finding it and beating you to the punch. If you are doing it >> for profit, then you don't share. That's where the side effect is > > I think there is another dimension to this trend: for "sparse" > software, the challenge to identify new vulnerabilities and write > exploits for them is beyond the capability of most security > researchers speaking at industry conferences so this happens only > rarely. Many of the speakers work at consultancies that offer 2-4 > weeks of research time per year and the time-to-bug-discovery for > sparse targets is more likely measured in years, without even > considering time-to-exploit. > > On the other hand, what is the media value of a conference talk on yet > another bug in Firefox? It's possible for Mozilla to purchase such > information nearly at-will for sub $1000, ditto for many other popular > targets. If, as an organization, you are investing in tools and > research to find densely populated bugs at increasing rates of speed > and you widely disseminate the tools and knowledge to do so then you > are, in effect, arming your adversary since you will likely never > reach the bottom of the bin. At the same time, hackers from the 90s > have grown up and there are now professional groups ready to harvest > this reusable information. At some level, I think many researchers are > aware their work will get used this way and disclosure, consciously or > unconsciously, has shifted as a result. > > Either way, this seems like nothing to be upset about. For sparse > targets, the work has been done to secure them to a reasonable degree. > For dense targets, additional disclosures will do little and I would > focus on rearchitecting, exploit mitigations, or deployments that > acknowledge their inherently brittle state (for example "apoptosis," > as Dave refers to it). I think this helps explain the movement towards > "stunt hacking", since consultants are incentivized to focus on > targets that are dense, that maximize media value, and that minimize > disclosure risk. On the plus side, the utility of industry conference > talks to professional attackers appears to have dramatically declined. > > I think Microsoft understands this concept based on the design of > their bug bounties. For example, their IE bounty only ran for 30 days, > which seems like an acknowledgment that it would be impossible to find > all the bugs in an application so densely populated by them. Rather, > as a developer I want to know whether some components are worse than > others, how many people can find and exploit my software, and what > skills and tools these people have. I think it’s only a bonus that > Microsoft patched a few bugs in the process of collecting this > intelligence about IE. > >> If a couple of Texas brothers could corner the world silver market,[HB] >> there is no doubt that the U.S. Government could openly corner the >> world vulnerability market, that is we buy them all and we make >> them all public. Simply announce "Show us a competing bid, and >> we'll give you 10x." Sure, there are some who will say "I hate >> Americans; I sell only to Ukrainians," > >> This strategy's usefulness comes from two side effects: (1) that >> by overpaying we enlarge the talent pool of vulnerability finders >> and (2) that by making public every single vuln the USG buys we >> devalue them. Put differently, by overpaying we increase the rate >> of vuln finding, while by showing everyone what it is that we bought >> we zero out whatever stockpile of cyber weapons our adversaries >> have. We don't need intelligence on what weapons our adversaries > > To return to your original question, "should the US create a 10x bug > bounty?" Since there is software where bugs are dense, I think the > answer is clearly no. Such a system might even implicitly reward the > developers of the most horribly architected software. However, I don't > think it makes sense for the specific targets that are sparse either. > Is it worth the man-years of effort to find those remaining few bugs > or would that investment be better spent continuing to refine their > architecture and pursuing formal verification that proves the absence > of bugs? > > That said, I think the for argument for having a “national bug bounty” > is to make the choice for independent researchers competitive - do you > sell to [name a country], or do you sell to US-CERT? What if they’re > both paying the same price? What if by selling to US-CERT, you get a > byline on some website and retain the freedom to talk to whoever you > want about your bug? Then maybe if some random Geohot-alike stumbles > over a tcpip.sys 0day, they sell it to CERT instead. > > I think that one advantage of bug bounties is that they are inherently > passive. You have to pre-commit the money and vet bugs that come in, > but you’re not expending effort on a team of people to look for stuff. > It’s passive and opportunistic. > > So what if the US-CERT bug bounty worked like this: we identify > software that contributes to the “national information infrastructure > base” which is like, browsers, routers, phones, and Windows. We award > big bounties for stuff in that category. The rest of the world > continues finding bugs in whatever it deems necessary. Maybe it takes > a few years for someone to shake out a new IOS bug, but that’s okay, > the bounty isn’t paying out over the time of the search. > > Although obviously, it’s better if we build it right the first time so > what I’d offer is why don’t we do both? Having a bug bounty in place > of real security is obviously foolhardy. What if the government > identified software that was in the “critical path for civilization” > and gave the software vendors that created it a choice, provide: > > a. A formal proof of correctness for this software, along with > rigorous testing methodologies and open design / open source so that > others or at minimum the government could verify the systems > correctness > > b. A ton of money that goes into a US-CERT slush fund to pay out > bug bounties > >> Machine-powered vuln creation might change my analysis >> though I can't yet say in what direction. > > I think that mechanized vulnerability hunting a la DARPA’s Cyber Grand > Challenge fundamentally changes much of this balancing act. In theory, > it holds potential for those in ownership of software densely > populated with bugs to find nearly all of them at once. _______________________________________________ Dailydave mailing list [email protected] https://lists.immunityinc.com/mailman/listinfo/dailydave
