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

Government Oversight

[Anonymous Coward]

What we need is a government office that handles this sort of thing, because National Security can depend on bug fixes.

There needs to be a law against releasing exploits without giving the comapny time to react to the find.

Perhaps there should be a software developers association that a company can join that handles oversight on this issue. Any "hackers" that find a critical bug with a piece of software could bring it to the association's attention, and there could be sanctions if the developer refuses to fix it.

Re:Government Oversight

[Anonymous Coward]

The idea is not to make a government commission that tests every piece of code Microsoft or Apple writes. Rather, the idea is to have a goverment commission that handles the release of bug information to the general public.

If the bug can be quietly fixed without harm to the public then the developer is given time to fix the problem. If there are several exploits in the field then the general public is warned and a fix is made as soon as possible. The commission would have the power to envorce a law preventing Joe Hacker from releasing exploit information on the web and claiming free speech.

What you fear and what reality is are two separate things. A general disdain for the goverment is not a solution to our problems, no matter how many times you use it as a blanket response to the various problems we face in modern society.

Re:Government Oversight

[RotateLeftByte]

Nah,
  We would still be using Paper Tape loaded through an ASR33 Teletype :-)

Seriously though,
  Exposing bugs like this is (IMHO) a pure FUD stunt. Ok, tell the vendor about the bug and if they don't fix it in a reasonable time (variable depending upon severity etc) then by all means publicise the problem in order to get some pressure on them to fix it.
But getting Officialdoom involved? You are a prime candiate to be sectioned. Civil Servants the world over can't organise their way out of a paper bag let alone something like this.

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.

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"

Re:Opinion Swing?

[susano_otter]

people who are using the software have a right to know that it is vulnerable.

I think such a "right" (I would call it an "entitlement", actually) really only makes sense if there's a reasonable expectation that general purpose computing in a networked context is safe and secure to begin with.

Given the true nature of computer networking today, far from having "rights", I'd say that software consumers have responsibilities: To avoid networking except with known good components; to develop their own software in-house so that they can better control the vulnerability testing and patching process, to conduct their own testing to their own standards on third-party software; and to not pretend that all their security problems are the responsibility of the third-party software vendor, easily solved by the vendor simply writing perfect software.

Re:Opinion Swing?

[mstone]

---- To avoid networking except with known good components;

Components are only part of the story.

According to the Orange Book (the DOD manual for evaluation of trusted computing systems), the security of a machine can be rated no higher than the rating of its least trusted port. That includes everything, including the power cord and the air. A truly high security system demands a generator inside the same Fermi cage as the device itself, and probably armed guards at the door.

The internet is an untrusted and untrustable network. Connecting to it voids your security rating, period. There are no cryptographic protocols or techniques that can possibly make it secure. Read Bruce Schneier's Secrets and Lies for a complete, technical, and eloquent discussion of why not.

---- to develop their own software in-house so that they can better control the vulnerability testing and patching process

BAD idea. The single biggest source of exploitable holes is roll-your-own software developed by people making things up as they go rather than using well-known, well-analyzed, mature designs. Security experts still prefer 3DES over say, blowfish, even though blowfish is more resistant to analysis. 3DES has a 30-year track record of holding its own in spite of being analyzed every way imaginable, and blowfish doesn't.

You're forgetting two basic facts of security: One, that trust always starts somewhere. Two, that lack of trust is expensive.

Your proposal boils down to a radical lack-of-trust agenda, with two major flaws: The first is that it just doesn't work, because you have to trust someone, somewhere, sometime, and as soon as you do you create an opportunity for expliotation. The second is that you haven't given serious consideration to the costs associated with lack of trust.

Most security experts say that the best general strategy is "trust, but verify."

With regard to vendors patching their own products, you put that theory into action more or less the way the responsible security agencies do now: notify the vendor privately, give them a certain amount of time to respond, then post a public notice of the kind of problem along with a severity rating and a general description of what parts of the product are vulnerable. In other words, give people enough information to know a risk exists, but don't give the script kiddies a fully-automated exploit kit. That gives the public enough information to count the unpatched-vulnerability-days for a given vendor and make a decision about how much to trust that vendor, without artificially escalating the risk users face.

This MOAB stunt is bullshit because Apple's track record of acknowledging and fixing reported vulnerabilities is only one of his secondary concerns. Mostly, he just wants to instill what he considers a healthy level of FUD among Mac users, since in his opinion Mac users are complacent, and complacency itself is (according to him) a security risk. He honestly seems to think that a good helping of Fear, Uncertainty and Doubt will be good for everyone.

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:Nothing...

[Mixel]

And in financial news, "Economists Disagree On How, When To Invest Money"

I already talked about this.

[CherniyVolk]

In one of my previous posts, I have already talked about this.

Companies have no other interest or goal other than to make money. Fundamentals people, fundamentals! If you think, for one second that an idea from any company not resulting in immediate profit is correct, you are a fool. They cut corners, discriminate based off of accredited and formal education rather than will and raw expertise and experience, they implement managment schemes that do more harm than good for the sake of book keeping for VCs and shareholder confidence. They have to make every judgment off of a cost analysis report. And what few people understand is, if it's cheaper to continue in the same path, they will even if people are dieing (car manufacturers) or getting screwed (Microsoft software unreliability).

I can't believe this debate is taken seriously! The Companies want this precedent, because it's cheaper to ignore most exploits than to actually have to hire someone that can do something to better the software. Companies want this because it adds another variable (in their favor) to the cost analysis of fixing a problem... it gives them choice. And as we all know, from Companies' own assertions, that choice is bad and force is the only thing applicable. Companies don't give you much of a choice, why should you give them any? Open Source doesn't get a choice, why should their competitors (proprietary software). If Capitalism is the so-called "best", then it should be able to compete in the exact same fashion and prevail as other systems. So don't do this double standard crap of "Oh, if it's a company software, do 'X' if it's not, then do 'Y'; only because of a benevolent precedence suggesting you should give a Company a break while it's OK to lay hard and firm on some other ideology."

If a Company releases software that is buggy. The very instance you find an exploit, it should be released to the public with all that you have researched including example exploits. If the Open Source community can fix it quickly, then surely Microsoft or Adobe can too with their all-mighty Capitalist ideals and absolutely-necessary 'management'....

There is no precedence here. It is not a debate. You paid for the software, and if you don't get what you paid for (and some), then you should have absolutely NO qualms of sticking it back to the person who pawned it off to you. If they are so great, then let them prove it. But they aren't, and that's why they are coming up with all these little social tricks trying to get people to make an exception to further propogate the illusion that proprietary software is "good" the "best money can buy" or what ever.

You paid for the software. It's yours. You got screwed. Let people know! If you got screwed at the used-car lot, you'd let your friends know the details... you'd even feel socially obligated to do so. Software is NO different. You are socially obligated to blow the whistle for every little thing you find, and blow it till you're blue in the face; you paid for it, and you didn't get what you expected. It is NOT illegal to blow the whistle on crappy products you end up paying for. In fact, for some products it's a federal offense to pawn off crap to the consumer (think Lemon Laws in the United States). If you really want to get technical, then there already is legal precedent set in this regard because it's illegal to sell a car that is reasonably too problematic in the United States. Maybe we should make it illegal for software Companies to release crappy and overly buggy software too!

If you find an exploit. As soon as you can write up a concise report, sample code et al. and hit the "Send" button. DO IT!

Re:2 months

[Lord Ender]

The problem with setting any reasonably lengthy period of time is that it results in that much more infection and use.

Wow. Do you have any evidence whatsoever to back that claim up? Or did you just see it on IRC somewhere?

Back in reality, it is almost universally assumed that published exploit for which no patch exists will lead to much more damage than a published exploit for which a patch is widely available. In fact, it is so obvious (to almost everyone but you) that such a study has never even been performed.

The security community shuns researchers who publish exploits without allowing vendors a chance to patch. Security researchers who practice "full disclosure" instead of "responsible disclosure" are widely considered malicious and immoral.