[Dailydave] software security, disclosure, and bug bounties

[Dan Guido]

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