pseudo-flaw.net

There are numerous stances that a researcher can take when disclosing a possible security vulnerability. The first is to do absolutely nothing -- simply hold onto it in the hopes that it can be leveraged in the future. Obviously, there is not much disclosure happening and the vulnerability will most likely never be addressed. Other, more public methods, are awareness, advocacy and grandstanding.

Awareness can come in many forms. The best form of awareness is to report the security vulnerability to the vendor and work with them to see that it is resolved. Most often, this can be done is a private and responsible manner. The information security landscape has changed in the last several years and most vendors are willing to accept and accommodate security bug reports.

Another way to raise awareness is to publicly post details of the vulnerability to blogs, mailing lists, and forums prior to notifying the vendor. That traditional "full disclosure" mentality may still have merit, but the time is long past when this is considered a truly productive method of information sharing. If that goal of security is to make people safer, publicly disclosing newly discovered or previously unknown exploits prior to a patch being made available is not furthering that goal.

Occasionally, though, recalcitrant vendors refuse to acknowledge privately reported security vulnerabilities or won't address publicly reported vulnerabilities and continue to ship exploitable products. In these cases, advocacy is an appropriate approach. This could involve simply creating an exploit for the vulnerability and releasing it. The example attack should do more than just the regurgitate the proof-of-concept in the original vulnerability. It should show a real world version of the attack and meet some defined goal. If those actions can be accomplished, more widespread dispersal of that information is appropriate, be it through forums, blog posts or mailing lists.

But, if a real-world attack cannot be constructed, the vulnerability is best left to drop until an exploit can be developed. Continued broadcasting of a questionable vulnerability is nothing more than grandstanding. Spamming mailing lists and making copypasta forums postings of half-baked ideas does not engender much respect from the community at large. To be a bit hackneyed, either "Put up or shut up", and if you can't, "quit while you're ahead".

Claiming to have some significant exploit and then refusing to release it because "it's too dangerous", rings quite hollow when it is discovered that the vulnerability was never reported to the vendor in the first place. It is also poor form to recycle vulnerability reports against a product when the vendor has addressed it in most recent supported versions. Taking a well-known, publicly reported vulnerability and hyping it in some sort of attention grabbing attempt is quite distasteful. These shallow stabs at fame-mongering are simply useless if they don't make positive contributions to the community dialog.

And sometimes, it is as much a matter of presentation as it is content. Making a conscious decisions to not take part in the established process and then later railing on that very same process does very little to improve ones professional image. A history of such behavior leads to reputation that is hard to shed, no matter how much quality or relevance some information has.

To put it plainly, if I have to ask "Is this bogus?" every time I see post on a given blog or from a particular individual, I will be much less likely to trust the source of that information over time.