Hackers Disagree On How, When To Disclose Bugs

darkreadingman writes to mention a post to the Dark Reading site on the debate over bug disclosure. The Month of Apple Bugs (and recent similar efforts) is drawing a lot of frustration from security researchers. Though the idea is to get these issues out into the open, commentators seem to feel that in the long run these projects are doing more bad than good. From the article: "'I've never found it to be a good thing to release bugs or exploits without giving a vendor a chance to patch it and do the right thing,' says Marc Maiffret, CTO of eEye Security Research, a former script kiddie who co-founded the security firm. 'There are rare exceptions where if a vendor is completely lacking any care for doing the right thing that you might need to release a bug without a patch -- to make the vendor pay attention and do something.'"

Comments

Opinion Swing?

[bmajik]

It's good to see that opinion seems to be shifting on the matter.

A few years ago when Microsoft started pressing for "responsible disclosure", they were pretty much mocked and ridiculed by everybody.

I'd like to think that there is now some real discourse on the effectiveness and responsibility of full disclosure vs responsible disclosure, and that security researchers are choosing responsibile disclosure more often.

I'd prefer to think of things that way then to cynically surmise that this is simply a case of "when it's an MS bug, let's roast them with a 0-day disclosure, but if its anyone else, let's give them a fair shake at fixing it"

One problem

[daveschroeder]

One problem in this debate is that often, either side will make it seem like an all-or-nothing proposition; that it's either "full disclosure on day one" (or in this case, "day 0" ;-), or it's feebly report to the vendor and wait helplessly while the faceless vendor takes months to respond, if it even responds at all.

There actually is a middle ground.

Some say, "Hey, these vulnerabilities exist whether they're reported or disclosed or not," just as MOAB says in its FAQ. But the problem is that they overlook the practical side. Sure, the vulnerabilities, and maybe even working exploits, exist, but as long as they're hoarded (and not used) by very small and tight-knit groups of people, they're not getting actively exploited in the wild across massive userbases. Could high value 0day exploits perhaps be used for isolated penetration? Sure. But could they be used (for any period of time) for a mass-spread worm or other malware? Nope. It'd be hours before security firms and/or vendors identified the issue.

So when you choose to disclose previously undocumented issues before giving the vendor any chance to respond, which some claim they're doing to improve security, there is a greater chance of exploit across a much wider base of users, which can have a much wider and catastrophic impact. Some say that as a sysadmin, they'd want to know about such vulnerabilities so that they can protect and mitigate themselves. But other than for high value targets and corporate or government espionage - which can perhaps have their own channels for "earlier" disclosure when identified by entities like US-CERT or Information Assurance agencies - I don't see how people can reasonably expect to be targeted by extremely valuable and as-yet-undocumented vulnerabilities. It's a point of pride - and sometimes money - to sit on such vulnerabilities.

The bottom line is that the vendor should always be informed in advance, if there is any real concern about security on the platform, and not just ego stroking or slapping down "fanbois". How long in advance and how long a vendor should be waited on is somewhat subjective, of course. Also, no one's saying that an "independent" "security researcher" is beholden to a corporate interest. But then they shouldn't operate under the guise of responsibility or the feigned notion of wanting to "improve security", when some persons' mechanisms for disclosure are nothing more than PR attempts, or another notch in the bedpost (hmm, or probably NOT a notch in the bedpost...)

Re:Government Oversight

[causality]

The summary and article talk about withholding the exploit information until the vendor is able to release a patch, as though this is the only possible scenario that could be happening just because it's the only other option (as opposed to immediate full disclosure) happening today.

But the most egregious examples of "Find security flaw -> Issue patch -> Wash, rinse, repeat" are found in programs (Sendmail? Bind, anyone?) or operating systems (Windows .. 'nuff said) where security was an afterthought that was bolted-on later. What I would like to see is complete and instant full disclosure that is sufficient and inevitable enough to encourage vendors to make this entire model obsolete, namely by making it no longer practical to handle these issues by issuing patches. This would provide an incentive to redesign from the ground up with security in mind so that many of these issues don't happen in the first place, and the ones which occur are reduced in severity.

Consider the OpenBSD approach, where security was a priority from day one, and the excellent track record they have in this area, and contrast it with Microsoft's track record, where only marketing was a priority from day one. The only way this will change is when it is no longer profitable to place such a low priority on security, and the two ways you arrange that are by demonstrating that the current situation is an arms race that is not sustainable, or, by waiting for a day when Grandma and Joe Sixpack care about computer security enough to refuse to buy anything that doesn't deliver it. Personally, I find the first option to be far more realistic, and it also helps to avoid the "only two choices" dualism that I keep seeing everywhere (especially in politics... "Democrat vs. Republican", "Left vs. Right", "With us or Against us") that is suffocating real change.