[Dailydave] software security, disclosure, and bug bounties

[Michal Zalewski]

I don't think I subscribe to the school of thought that assumes there
is no value in finding bugs in software that is known to be densely
populated with them.

Sure, some software is designed and written better than others, and it
is easier to reason about its security - although tellingly, we're
*really* only comfortable making that assertion after empirically
looking for bugs, not after making a high-brow literary critique of
the design doc. But there's plenty of third-party software that you're
stuck with, and you can't really make any safe-bet and cost-efficient
"investments" into making it more secure. You're probably not going to
rewrite the Linux kernel, or even ffmpeg; even if you did, it probably
won't catch on for reasons beyond our control.

Resource-wise, you could probably rewrite libjpeg-turbo and make it
safer... but you're not going to, right?

In that setting, sure, putting "man-years" of time into finding a bug
in known-buggy software is a waste of time, but that pretty much never
happens. It's easy to glorify run-of-the-mill vulnerability research
or portray it as something incredibly expensive. In practice, lots of
it happens in partly automated and highly scalable ways, and can
happen very cheaply. Governments have gotten into bidding wars and
inflated the payouts for more opportunistic researchers, but really,
it's almost never "man-years" to find and exploit a bug.

More interestingly, when you start squashing these individual bugs
fast enough, you can probably gain a fair amount of confidence in the
formerly-horrible piece of code, and make it a lot harder for other
researchers to find and exploit one. My favorite example of this is:

http://googleonlinesecurity.blogspot.com/2014/01/ffmpeg-and-thousand-fixes.html

Today - yeah, there probably are some leftover bugs in the few ffmpeg
codes that are exposed through web browsers. But you need to be pretty
lucky to bump into them.

We're not going to rewrite the world in Erlang or make every developer
on the planet understand the subtle risks of C/C++, and the reality is
that we need to attack problems from multiple angles, rather than
making dogmatic statements about not caring about individual bugs;
more often than not, proclamations like that are used to paper over
long-lived problems in legacy codebases, instead of facing them
head-on.

I also find it interesting that we tend to glorify SDLs while
simultaneously ridiculing the checkbox-driven absurdities and
ineffectiveness of PCI - which seems a bit schizophrenic. In reality,
of course, both of them are very flawed tools, and get oversold a lot.
Microsoft Office had an security-oriented SDL for a decade, Open
Office probably did not; vulnerability-wise, it's probably hard to
tell them apart.

/mz