[Dailydave] software security, disclosure, and bug bounties

[Mathias Payer]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

I agree with mz on most points. While I agree that finding bugs is an
important problem (and should be done, frequently, and in great depth
and breadth) there are some problems that remain.

Two problems we face are:
a) some residual bugs remain (but at higher cost for an attacker)
b) new code is being written faster than we can reverify/refuzz all
the software, so there will always be some attack surface that stays a
moving target.

We'll have to accept that all software may contain some exploitable
low level memory corruption (or even other vulnerabilities). Solutions
like Code-Pointer Integrity [1] or Control-Flow Integrity protect
applications against control-flow hijack attacks at low to negligible
performance cost. Recompiling applications with some effective defense
mechanism that cannot be mitigated should definitively become part of
our toolbox (and used in distributions by default just like DEP).

Cheers,
Mathias

[1] Code-Pointer Integrity. Volodymyr Kuznetsov, Mathias Payer, Laszlo
Szekeres, George Candea, Dawn Song, and R. Sekar. In OSDI'14.
http://nebelwelt.net/publications/14OSDI/

On 11/24/2014 12:56 PM, Michal Zalewski wrote:
> 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 _______________________________________________ Dailydave
> mailing list Dailydave at lists.immunityinc.com 
> https://lists.immunityinc.com/mailman/listinfo/dailydave
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCgAGBQJUc6MUAAoJEE5jPvE6BIgIORAQANGYYmMeqQy28nuxGIjCDCVe
sGKk6jBIMShPMWFpix4NXxlWObtcrYyh+5Vv4ONRwKmP3OMSolnEOdG3v1k1jB/L
xyqwfb49G4LJ9mmKNjC4+vlSeU+Ao9yzDj3PNycWjUIbvhcuXtczStx7UWYgpzks
WzlVgxDSCQzw6vmMfZIa2F9AZbXk/+b0ZG3yu+EByIibZuz1ly84uY4hMFVn6ozF
mdmAwulWQ8oMYFuGd2J7mjVt7iWn3ZKdpHpl5wqlWM4VXvapREVHEXq5FwaR9741
Sv80xbbV6dM9lL/JDiP07LnD4CADnyQxuZFej+O+Vsx+BGB3822exohfrHnfUjMi
aoVuYHme4uwIDMLSgUdavnpeFZFBY38pDI+m4Lby4QsmPN2SILInU8qYPtKzN8eK
tANYeE7eXD8FpgAnsVRO8LWbiIbfZrYrpzrz4BmAzFR2qRA4YolLUhJI1xlmAHPD
wSc7sNLXC/IbauAZPpParA3qpqBPnSkQldv/3f1k5/Rncx67/4xD9Aud3Lr4jkDA
8pUS1B7hT+U2jdyIT9ZAINnQSSuuBXyN6H9uZ0sIzM3CM9LhBoljteMRItFrGC+2
ljFuTDIetRuM4qgYRlV4zqxU4p9gWDKKjP1QstBfA+wjWNeSTHxlGgtWZlqxX6vP
Sdjz2x3afOR2mMeEKVt7
=1HC/
-----END PGP SIGNATURE-----