Dailydave mailing list archives
software security, disclosure, and bug bounties
From: Dan Guido <dguido () gmail com>
Date: Sun, 23 Nov 2014 14:07:47 -0500
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 sparsely 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 money 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. -Dan _______________________________________________ Dailydave mailing list Dailydave () lists immunityinc com https://lists.immunityinc.com/mailman/listinfo/dailydave
Current thread:
- software security, disclosure, and bug bounties Dan Guido (Nov 23)
- Re: software security, disclosure, and bug bounties Michal Zalewski (Nov 24)
- Re: software security, disclosure, and bug bounties Mathias Payer (Nov 24)
- Re: software security, disclosure, and bug bounties Michal Zalewski (Nov 25)
- Re: software security, disclosure, and bug bounties Dave Aitel (Nov 25)
- Re: software security, disclosure, and bug bounties Mathias Payer (Nov 24)
- Re: software security, disclosure, and bug bounties Michal Zalewski (Nov 24)
- <Possible follow-ups>
- software security, disclosure, and bug bounties Dan Guido (Nov 24)