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.'"

Nothing...

Nothing for you to see here...

In other news, "Slashdot Editors Disagree On How, When To Post Stories."

Government Oversight

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

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

worst... idea... EVER.
Ever seen the red tape and shit that govt brings with it? Christ, we'd all still be using telnet.

Re:Government Oversight

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.

2 months

I'm all for informing the company (not just email, get verification the right people got your information) and then give them 2 months.
1 month for them to fix it, 1 month for the customers QA and patch their systems.
Beyond that, it's usually feel dragging but I'm sure there are exceptions where you would release earlier or later than that in some cases.

Re:2 months

The problem with setting any reasonably lengthy period of time is that it results in that much more infection and use. Basically, this grants any purchaser of a 0 day exploit roughly a 2 month window of opportunity to use their new found investment.

Where as there may not be a patch to solve the problem, but perhaps there is a significant work around that could avoid some trouble.

This is exactly why it is difficult to assign a window of disclosure to such issues. Not too terribly long ago, some of the larger firms managed to get together and settle on a 30 day notice.

Also, you might also remember that a little company called Cisco was sitting on a vulnerability for quite a while until someone when psychotic over the deal.

In the grand scheme of things it comes down to protecting your image. It almost seems like the policy on vehicle recalls. Unless X number of issues arise... just don't deal with it. However, if it becomes substantially used or finds the public eye... it suddenly becomes a much larger problem.

Honestly, an arbitrary date is rather inflexible and a system that takes in effect the impact of the bug needs to be used. Pump out tons of crap software? That isn't exactly the problem of the common man, but rather the problem of the organization's software development model.

Organizations and individual people lose time and money to support these industry bug shields. Again, a case by case determination depending upon the level of potential harm.

Opinion Swing?

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?

You seem to assume that the exploit won't be discovered independently by someone else who isn't quite so altruistic. If they won't fix it, people who are using the software have a right to know that it is vulnerable.

Re:Opinion Swing?

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?

You are operating under false assumptions.

There exists a community of underground hackers (crackers?) who search for exploits. They find them, trade them, sell them, and use them to steal data and resources. Gone are the days where script kiddies just hack for fun; there is a serious black market involved, since resource and identity theft can be very lucrative.

When an exploit is discovered by a researcher, it is likely that the black hats have already discovered it. The software's users are already being harmed, although they may not realize it: smart hackers are good at covering their tracks.

In this scenario, "responsible disclosure" is anything but responsible. By waiting until the vendor has patched the software, users are being harmed. On the other hand, immediate full disclosure has three important effects:

One, it eliminates the black market for the exploit. If everyone knows about it, nobody will pay for it. This reduces the overall market for exploits and, compounded over many exploits, will drive hackers out of the market. If it is not profitable to find exploits, fewer people will do it.

Two, it gives the users an opportunity to take action. If, through full disclosure, I find out that Internet Explorer has a serious security risk, I can switch to Firefox. If my Cisco router has a problem, I may be able to work around it with an alternate configuration. On the other hand, if a researcher reports the exploits to Microsoft and Cisco directly, black hats are free to exploit my computer and my router until patches are released (if they ever are).

Three, it provides an incentive for vendors to write better software. If every software bug meant a black eye and angry users, you can be sure that there would be better software. On the other hand, the occasional well-timed patch looks like software "maintenance", a concept that shouldn't exist but sounds reasonable to the layman (after all, he has to have his car tuned up every so often, so why not his software?) The result of full disclosure, on the other hand, is more akin to an emergency recall; the producer has clearly made a mistake.

The concern, of course, is that the black hats don't already have the exploit, and that full disclosure gives it to them. Yes, this is the risk of full disclosure. However, given that black hats have an economic incentive to find exploits, while researchers rarely do, we can expect the probability of this to be low. And even if they don't have the exploit, releasing it still shrinks the exploit market (why pay for exploit B when you can get exploit A for free), it still notifies users of a potential problem, and it still incents vendors to write better software.

Full disclosure is responsible disclosure.

There's another story along these lines....

.... at news.com:

http://news.com.com/The+good+and+the+bad+of+bug+ca mpaigns/2100-1002_3-6147026.html?tag=nefd.lede [com.com]

imagine the job interview

March 1996 to April 1998: I was a script kiddie in my mom's basement.

/not that there is anything wrong with that...

Wow

"'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.

And who are you, miss Kelly Jackson Higgins, to make Mark Maiffret a former script kiddie, where did you get this fact?

The problem is...

If these bugs aren't publicly disclosed many software vendors see no reason to fix them. The reason for this is each time you fix a bug the product has to go back through a full QA cycle - which can cost lots of money.

One problem

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...)

THIS JUST IN...

Now, in breaking news, polarizing issues cause people to disagree! Film at 11:00!

Depends on the nature of the bug

If the fix is as easy as closing ports 135, 137, 138, 139 and 445 in the firewall, then you can disclose it immediately...

It really depends

I think that "responsible disclosure" is fine for companies that:

1) Make real attempts to release secure software, rather than just ship shoddy software as fast as they can onto the unsuspecting public.
2) Have a serious method for responding to issues quickly and effectively when they are found outside the company. This really just means good customer support combined with a good method of patching shipped code safely and effectively.
3) Treat security researchers as friends who help improve their products.

For other companies whose arrogance and lack of understanding are obvious ("Unbreakable" anyone?), I think that full disclosure is the most responsible action by a security researcher. These companies are doing the equivalent of shipping cars without airbags in the modern world, and then in many cases lying about it. That behavior needs to be "shocked" out of them, and for that reason, I think "30 bugs in 30 days" kinds of exercises are good for the software community overall.

In other words, "The beatings will continue until morale improves." ;)

Nuanced

Giving the vendor a few weeks to create a patch before releasing an exploit is a polite thing to do for the vendor's sake, but what about the users of the vulnerable software? Hiding potential threats from them keeps them from protecting themselves. Even without a fix, you can apply a workaround or if you need serious security, even replace the buggy product. I think that researchers who find security bugs should report the fact that a vulnerability exists in a given software product immediately. They can wait to release working exploits if they want to be nice to the vendor. Moreover, any legal restriction on releasing exploit code would be totally unethical. Code, even malicious code, is a form of free expression.

All's fair...

Hackers are not under any obligation to disclose anything. I'm not aware of any law that either forces them to disclose a vulnerability that they have discovered, or any due process that must be followed to do so. I'm also not aware that writing or distributing proof-of-concept code is illegal. Judging by the number of large software vendors either in court (IBM, SCO) or deliberately misinterpreting existing legal documentation (Microsoft and Novell attack the GPL), the law is clearly the only deciding factor in how business will be done in the IT industry.

Therefore, throw your morals and principals out the window. This is laissez-faire economics at it's best. Mud-slinging, sabotage, legal wrangling, death threats and more await as we determine just who has the best software. If these vendors are truly interested in some good-faith reporting from the people who are discovering the vulnerabilities, maybe a show of good faith on their part might be nice. There's absolutely no incentive to do anything in a reasonable or "nice" way, when dragging a hated vendor's name through the mud is both legal and cool.

There's a few things I can think of that would improve matters and reach a common ground where truly malicious software is written only by a few bad apples:

• Laws governing EULAs would reduce the weasel words that we click through blindly as we install software. Many EULAs that I've read actually have a clause that's different for the country of Ireland, as their so-called "lemon law" also applies to software. The EULA as it is written for the United States waives too many consumer rights to be valid in Ireland. Having clear guidelines for what rights you can waive by agreeing to a software EULA is vital.
• Vendor incentives for disclosing information in accordance with their company policy. When RSA was released to the 'net community at large, there was a sizable reward for proving the ability to crack it. If vendors offered some kind of financial incentive to disclose bugs through their normal process, many people would opt for the immediate cash rather than going for the jugular.
• Establish criminal and civil liability for writing bad software. Everything goes to a civil court these days, so it's often a battle of who has the better lawyer (mostly because there's no good laws governing EULAs...). What is the software provider's responsibility? Establish industry guidelines for QA testing for off-the-shelf software. Throw some people in jail for writing malicious software. Any company that misrepresents its software for the purpose of taking control of someone's machine should be subject to criminal liability. I don't want to hire a lawyer and roll the dice on a lawsuit. I want the police to press charges and the DA to prosecute, all without my involvement (unless I get to testify).

Just to be perfectly clear: I am condoning the MOAB and any other MOxB. I've used too much bad software and seen too many vendors be held utterly unaccountable for their pre-meditated actions against the consumer. Lobby groups funded by these large vendors continue to erode consumer rights. If this is not how business is to be done, perhaps the industry leaders should set a better example.

mandelbr0t

Hackers also disagree on...

... which Maria Sharipova poster is the coolest. ... which STTNG uniform best hides Romulan blood stains. ... baked or fried Cheetos. ... best way to get your parents out of the house for the weekend.

easy

How ever the hell I want. When ever the hell I want.

That's how and when.

I already talked about this.

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!

Here's the bibliography link again

Full disclosure debate [wildernesscoast.org].

You had me at...

..."hackers disagree".

You must release the information ASAP

If you don't, they may find away to get a court order to make it so you can't disclose instead of fixing it.

Or any of a number of dirty tactics.

Sorry, but even the briefest look at the history of corporate attitude indicates that they can not be trusted. This goes baco to corporation before America even existed, not just American Corporations. One reason Why I agree with Ben Franklin when he said that the constitution should ban corporations.

Can only be a good thing

Moves like publishing exploits immediately force companies to patch their software faster. Chances are that if the researcher knows about the exploit, someone else does who is already using it for nefarious purposes.

We need to form a panel...

...of the super leet who will serve as judges on a case-by-case basis. The, ahem, debugger, will submit his evidence that the company has refused to respond or address the bug in a timely manner. The panel will attempt to contact the company themselves as a last resort, and if this fails, will permit the release of the exploit. Eventually the panel will become drunk with power and corrupt, and retire in disgrace on billion-dollar yachts.

I nominate myself to head this committee.

One chance...

I've always believed in this simple procedure:

1) The problem is discovered.
2) The problem is reported to the vendor, the report including a fixed resonable date for either a fix or the date for the final fix (to allow for tough fixes). The time alotted reflects the severity of the problem - more severe results in less time.
3) When this fixed date or the vendor date (if given) is reached, the problem is disclosed regardless, complete with POC exploit if available.

This method forces vendors to take security reports seriously and it makes it THEIR problem if the the issue is disclosed before a fix is available. Aften all, if a security researcher can find the problem, so can the really bad guys and they will most certainly not advise the vendor, leaving a free avenue of intrusion that may last a long time.

Re:motto

Their called badges not patches, hello!

Oh, sorry. Just had a flash back to those boy scout days when they would hand out those little patches, I mean badges, BADGES, for being able to set things on fire and tie up your little bother in the name of first aid.