[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
