Dailydave mailing list archives
Re: software security, disclosure, and bug bounties
From: Michal Zalewski <lcamtuf () coredump cx>
Date: Mon, 24 Nov 2014 09:56:30 -0800
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 () 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)