Ethics? Aren't those the things that Bush outlawed? Or did they go extinct with the dinosaurs?

I think the ISC's CoE has it's flaws but it is better than no ethics. I think security companies should make it more clear that they are not interested in someone who has engaged in unethical behaviour and that acting responsibly is actually in their best career interests.

Who cares if a few corporations lose profits for poorly made software. They will sue you for releasing the vulnerabilities to the public, instead keep them to yourself and use them to do good in the world. Find out what you aren't supposed to know and share it with the world.

WTF, what kind of attitude is that? Just because SOME companies take such a bad approach to issues of vulnerability disclosure (ie: Cisco) doesn't mean you can lump all companies in the same boat. What good can you do in the world HIDING information?

I never said we shouldn't share it with the world. What I am saying is do so responsibly... allowing vendors to FIX the problem before you compound it with the likes of PoC code which leads to real exploits.

Hi Dana,

IMHO the Version was v9.25 8-)
(Last Updated: August 22, 2005 v9.25)

cu
Franky

Hey Franky,

Mark doesn't stand still. v9.25 just came out with some new features relating to the way it handles its tray icons. Now you can use the old-style tray icon if you don't like the new one. v9.25 does include the overflow fixes.

Calling researchers to task for at least trying to perform responsible disclosure is quite reasonable.

It is more difficult for vuln DB's and notification services. Many information consumers demand "best-available" information as soon as a bug becomes public. Vuln DB's have a much larger volume of information to deal with than individual researchers, so the complexities and labor involved with vendor notification are significantly increased (probably 50% of vendors don't respond to my email requests for more information). Improvements could be made, but this is a tough problem that vuln DB's cannot solve alone. Vuln DB's should not be forced into cleaning up the messes that others make.

Steve,

You bring up a good point. Vul DB's can't do it alone... and are much to resource starved to really review all submissions in detail. On the other hand, perhaps they should use a rating system or something to prioritize reports... reducing a person's rating when its found to be in error or reported irresponsibly. In this case, the original reported would be 'modded' down when a follow up report was sent in to show the indescretion.

Then again, many of the VUln DB's make money on their content. If they wish to do that, they should be investing in ensuring that the information follows proper guidelines. No one knew about this vulnerability until it was reported. They could have simply waited until they contacted the vendor and still got their information out in a reasonable time frame. Problem is, not all vendors are quick to respond... leave huge gaping holes in the process.

No right answer I am afraid. I do know this particular incident was handled wrong. And what worries me is that it seems to be a trend recently... I only hope it stops soon.

Time will tell.

"It took me less than a minute to see that v2.93 just came out and that there was no way that responsible disclosure was used in relation to this advisory."

Ok, how long did it take you to check the disclosure for the other dozen vulnerabilities released that day? How about the days when we see as many as 100 vulnerabilities released? Does it matter that SecurityFocus posted it 24 hours after other security sites did, and posted it likely knowing that it was already public?

You should also correct the version number above, as 9.23 was affected, not 2.93. If you ran a database, some folks may complain about the inaccurate information you provide as well.

Thanks for pointing out the typo "security curmundgeon".

As to your comments to checking the other disclosures, I don't think you are being fair. I never said it was easy. But I also don't PROFIT from the contents either. My point is that a process needs to be put in place to ensure that vulnerabilities are reported in a responsible manner. When incidents are found that didn't follow responsible disclosure, efforts should be taken to address this, and the security researcher should be repremanded in some way (ie: Delay further posts until verified from said author).

I sent an email to securityfocus on both the 20th and 22nd notifying them about this particular incident, and I still note that nothing has been updated on Bugtraq ID 14616. The solution still says "Currently we are not aware of any vendor-supplied patches for this issue.". That is NOT the case at all. Of course, they may just not have gotten to the emails yet. After all, it's only been a few days.

They had no problem putting the information online. Yet they seem to have difficulty updating the information. How many other incidents are like this?

As a final point, you are right that some folks may complain about inaccurate information if I ran a database and PROFITED from information therein. Of course I don't, and this is my personal blog where I write my thoughts in the digital realm. It's not spell checked, and parts could be inaccurate if I don't have the right information. But come on... it was a typo. All the reference links and information were correct.

Lets not all go out and kill the messenger here.

Thanks for catching the typo though. Much appreciated.

Dana,

Sometimes it's very tempting to rate researchers in terms of the quality of their information and/or how well they coordinate with others (coordination definitely improves the quality of information). The person or organization who publicly tries this would definitely make waves; vuln DB's might be forced into it if things get worse. However, too much public scrutiny might cause some beginning researchers not to disclose at all, and the current interest in research needs to be encouraged, IMHO. In addition, many disclosures are by unknown or almost-unknown researchers, which provides no solid information one way or another about the correctness of the reported issue.

It does seem to be a trend that there are more non-coordinated and erroneous disclosures, but there aren't any stats in this area. It is DEFINITELY a trend that more vendors are starting to go after vuln DB's, who are usually third party information providers.

Dana,

I am having trouble finding the disclosure of this vulnerability on the vendor's product page. Can you point me in the right direction? I also checked the Readme and Help files in the actual distribution.

Thanks for the help.

Stuart

Hey Steve,

Ya, its a sad reality. I see great usage of VUln DB's and definitely don't want them to go away. Vendors do a disservice to these systems when they chase after them, fire lawsuits or otherwise belittle and berate them (as we have seen with a few vendors now).

On the flip side though, I think that its fair to say that Vuln DB's need to act as responsibly as researchers and be reactive when things fall in the cracks. I don't want the Security Focus Vulnerability Database to go away. And I don't want researchers to stop posting. I just want to make sure that we follow some guidelines in how we disemminate and distribute the information. A fix exists from the vendor, and that should be updated. Of course, it would be nice if the vendor (in this case SysInternals) responded in kind to let the world know.

Hey Stuart,

I can't seem to find the information either, past the email I got directly from SysInternals.

I have sent an email to Mark asking where this information exists. Once I have a definitive answer as to where the information is located I will provide the update here.

Good point you indirectly bring up though. A fix is available and the vendor (SysInternals) doesn't seem to have a public disclosure of this. Would make sense that this should have occurred.

Stuart,

Mark just emailed me and informed me that the information is now in the changelog information at:

http://www.sysinternals.com/Utilities/ProcessExplorer.html

Thanks Dana!