Date: Tue, 7 Oct 2014 08:32:24 -0700 From: Michal Zalewski <lcamtuf@...edump.cx> To: oss-security <oss-security@...ts.openwall.com> Subject: Re: Thoughts on Shellshock and beyond In my view, "Heartbleed and Shellshock" is a weird way to frame the discussion. The OpenSSL heartbeat issue was, in many regards, a bug like many others; it is arguably eclipsed by hundreds of RCE / info leak bugs that crop up in browsers and in web app frameworks every year. It has gained prominence for a couple of reasons: - It came out with a sleek logo and a press package, - It affected a security-related library, making it sound a lot more worrying / bad than a bug "just" affecting IIS or Firefox, - It came on the heels of Snowden leaks and some vague concerns about Dual_EC_DRBG, so a lot of pundits started to arbitrarily imply that the NSA must have known (or must have planted the bug). Now, I give you that the bash bug was fairly unique and almost hilariously bad - but also a bit intractable. It dates back to the 80s, cropped up in a place where I certainly wouldn't think to look, and if there's one thing it proves is that... um, I guess, security people don't read books, since I bet that the feature must have been mentioned in at least some shell programming manuals? Before this finding, it genuinely wouldn't have occurred to most people that auditing bash is a good use of their time and money, not any more than it's a good use of your time to audit /bin/uname. ... The latter part of your article pivots to a more general question of "why bugs happen and how we fix it", and I think that's a good thing to ponder, although certainly one where it's difficult to come up with fresh ideas :-( The article pinpoints several factors, the first of which is lack of funding. This is actually probably a lot more significant for libraries that don't perform security tasks, but may be exposed in even more profound ways (e.g., how much money goes to libpng, ffmpeg, imagemagick?). But the argument for non-targeted funding is somewhat undermined by the fact that well-funded software seems to be about as likely to have bugs; if anything, funding speeds up the introduction of new features, and that's closely linked to the likelihood of vulns. All mainstream browsers have piles of cash thrown at them. Most of closed-source software is well-funded, too. ( More targeted funding may be more viable - say, rewarding specific security improvements or security audits. Say, we're doing https://www.google.com/about/appsecurity/patch-rewards/. But it's a tricky thing. ) Later in the article, you ask, "why doesn't every large IT company have a Project Zero?"; I think that the answer to that is usually pretty simple. Some of them may have not thought about it or didn't think it's cost-efficient, but most simply lack the in-house expertise to pull it off. There is a great shortage of skilled infosec talent - and in many companies, there is a strong emphasis on compliance and policy work, with technical stuff being an afterthought or something you outsource to a pentesting consultancy. It's also fair to ask if discrete security bugs are the most significant exposure we have to worry about. Both targeted and non-targeted attacks rely on simple phishing or non-0day bugs to compromise people; the bash bug is flashy, but most of the large breaches in 2015 will be probably attributable not to that, but to Bob in accounting clicking on dancing_hamsters.exe. How much money should we be throwing at fixing these problems? And how do we pull it off? /mz
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.