Part 1: Vendor statements

SF: What type of disclosure process should independent researchers adopt when they find a vulnerability?

Apple: For the protection of our customers, Apple does not disclose, discuss or confirm security issues until a full investigation has occurred and any necessary patches or releases are available. Apple usually distributes information about security issues in its products through this site and the mailing list Security-Announce.

People who find a vulnerability should report it to Apple via product-security@apple.com. It is analyzed and if it's a valid security issue, then a fix is developed and released. People who report issues are asked to keep the information confidential until such time as an update is available to customers. They can request a status update at any time through an email to product-security. People who work with Apple in the responsible disclosure process are credited in advisories for reporting the issue.

Computer Associates (William Taub, Vice President, Enterprise Security): There are several good policies (RFPolicy, OIS Guidelines, NIAC's Vulnerability Disclosure Framework, CERT's Vulnerability Disclosure Policy, etc) available that provide guidelines to help independent researchers disclose a vulnerability. When a responsible researcher discovers a vulnerability, they know it's important to contact the vendor whose product or service has been compromised quickly and professionally. Once a researcher has contacted the vendor - the vendor then needs to work together with the researcher to quickly address his/her findings and then disclose, to customers, the public, and/or any other parties who may have an interest (such as the government), the information and the resolution. Disclosure, when done ethically, shouldn't be about a researcher gaining publicity, nor should it be an attempt to attack or discredit a vendor. Instead, researchers should focus on taking actions that are in the best interest of the product's users and the Internet as a whole. To this end, ethical disclosure means working with vendors whenever possible. The vendors, likewise, need to ensure proper credit for the discovery of the vulnerability and offer a similarly professional and timely response. When a vendor's disclosure gives credit to the independent researcher who helped out, it tells us that this vendor cares about security; they appreciated and collaborated with independent researchers. It also tells us a good deal about the researchers. It shows they are ethical and follow an accepted process that is in the best interest of everyone concerned.

Google (Douglas Merrill, VP of Engineering): We encourage security researchers to follow responsible disclosure practices and notify us of an issue before they tell the rest of the world. This allows us to fix the issue before it is made public and help protect Internet users from security exploits. Security researchers can contact us at anytime at security@google.com.

IBM (Hershel Harris, VP of Development for IBM Tivoli software): The preferred process is that they disclose the potential vulnerability to IBM. We then validate and confirm the exposure and enter it into our security reporting process. This process categorizes the exposure and provides appropriate notification to affected customers, which could include a recommended process change, a configuration adjustment, or delivery of a product fix.

Microsoft: Microsoft continues to encourage responsible disclosure of vulnerabilities to minimize risk to computer users. Microsoft supports the commonly accepted practice of reporting vulnerabilities directly to a vendor, which serves everyone's best interests. This practice helps to ensure that customers receive comprehensive, high-quality updates for security vulnerabilities without exposure to malicious attackers while the update is being developed.

Novell (Crispin Cowan, Security Architect): While we recognize that independent researchers have a right to disclose in any manner they choose, we encourage and work with researchers who use what has come to be known as responsible disclosure. This is full disclosure, but with advance notice given to the product vendor or open source developer to allow them to prepare a fix before the vulnerability is disclosed.

Oracle: Oracle encourages independent security researchers to follow a 'responsible disclosure' policy. Researchers notify vendors about a vulnerability and do not publicly disclose information regarding the vulnerability until we have released a patch for it.

Red Hat (Mark J Cox, Security Response Team): Issues always take time to analyze, and my experience is that fixes where a vendor has had a few days to investigate tend to turn out better than where a vendor has to react in a crisis to a public issue. Researchers should always contact the vendor privately in advance. Where vulnerabilities are found that affect multiple vendors then an response team organisation like NISCC (www.niscc.gov.uk) can help co-ordinate communication. Advance notification doesn't necessarily make vendors slow to respond; a recent security issue was reported privately to the Apache Software Foundation on a Friday night and details were published with updates for all affected versions by the following Thursday.

SAP (Sachar Paulus, Chief Security Officer): SAP operates a security response service for taking care about discovered vulnerabilities by independent security researchers. They can simply send an e-mail to security@sap.com for notifying the issue. The disclosure process will be agreed on jointly with the independent security researcher, our aim is to fix the issue and inform our customers prior to public disclosure.

Sun Microsystems (Bob Brewin, Co-CTO of Software): For issues potentially affecting Sun products (including Java), independent researchers can send reports to Sun at: security-alert@sun.com. For more information, please see http://sunsolve.sun.com/pub-cgi/show.pl?target=security/sec.

The above address is the one place where researchers can send reports of potential vulnerabilities to Sun. However, researchers may also send reports for potential issues in Java to: java-security@sun.com.

Sun may release security advisories (Sun Alerts) for confirmed vulnerabilities. These advisories are released after fixes for affected supported releases are available and after we provide time for our licensees to address them in their implementations.

Sun coordinates with researchers on the timing of public disclosures so that they can release their advisories shortly after the Sun Alerts are published.

Yahoo! (Arturo Bejar, Head of Information Security): We take security very seriously at Yahoo!, and work to address vulnerabilities in a timely fashion. We encourage security researchers to first notify security@yahoo-inc.com of their findings, so that we can work together in resolving issues before publication.

Part 2: the disclosure process

SF: What type of disclosure process should independent researchers adopt when they find a vulnerability?

iDEFENSE (Rick Howard, Director of Intelligence): Before I answer the question specifically, let me run down the iDefense Vulnerability Contributor Program (VCP)for you:

1. Either iDefense Reverse Engineers or outside contributors discover a zero-day exploit and submit it to the iDefense Labs for review.
2. Once vetted within the lab, iDefense simultaneously informs the vendor responsible for the vulnerability and the iDefense customer base. iDefense does not go public with the information and neither do any of the customers. It is in their contract. If they did, we would know.
3. The responsible vendor takes time to vet the problem within their own lab. They have to develop a patch, [they] Quality Control it and then publish the patch. Microsoft and Oracle average about 120 days to do this. In the meantime, iDefense customers get 120 days of early warning because nobody else in the world knows about it. iDefense helps customers determine mitigation strategies for their enterprise until the patch comes out.
4. Once the vendor publishes the patch, iDefense pays the contributor.
5. iDefense also hosts quarterly challenges. We pick a topic with some very specific parameters. For every exploit we get during that quarterly challenge, we pay $10,000. The first quarter of 2006, the challenge concerned anything to do with Microsoft. The second quarter, the challenge concerned databases. This third quarter, we are doing browsers. Last month's Microsoft Black Tuesday list contained four exploits that we discovered during the first quarter challenge.

Some vendors would prefer that these exploit contributors stop doing what they do or, at a minimum, just hand over their research because they are good guys. Some vendors are willing to pay for exploits too. Many don't publicize the fact.

To be fair, some researchers do hand over their finds to the vendor at no cost. David Litchfield is a famous example. As you know, he supplies Oracle with all of the exploits he discovers. Last year at Black Hat he rather publicly demonstrated an exploit to the audience because he didn't think Oracle was moving fast enough to patch it. But he does not get compensated for his efforts.

Having said all of that, the iDefense VCP provides five main benefits that I can see:

1. The program finds zero day exploits that nobody would know about otherwise.
2. The program provides an outlet for those individuals, who are not necessarily bent on breaking the law, to get legally paid for their services. Without programs like this, these guys would have to turn to the dark side to get compensated (or work for some government agency).
3. Vendors get the research for free. iDefense does not charge them for it.
4. iDefense customers get early warning for zero day exploits.
5. iDefense acts as an independent, non-partial middleman for these independent researchers who desire to get compensated for their efforts. Without iDefense, independent researchers would have to negotiate individual contracts with each vendor; some of whom are not keen on paying for the research in the first place or sell the research on the black market.

There are benefits to reporting to the vendor first. Just like when reporting the vulnerability to iDefense, the vendor has a chance to create a patch before the world knows about it. Thus, the exploit would not impact the Internet at large because the vendor will not announce it until it is patched. For some researchers and security experts though, this is less than satisfying. This path may never cause the vendor to fix the problem. Indeed, there exists no impetus for the vendor to do so. The vendor owns the code and nobody else does. Nobody will pressure the vendor to make something happen; unless you are Dave Litchfield and change your mind at Blackhat that is.

Exposure on a public list without any warning will certainly cause the vendor to jump through hoops in an effort fix the problem. But that leaves a gap between the time when the exploit is announced and when the vendor can push out a fix that leaves the Internet vulnerable. The hacker gets his issue addressed but causes more risk in the process.

One avenue is that these altruistic researchers could hand the exploit over to iDefense or others like us and not take any compensation. The researcher feels good that his issue will be taken care of, the vendors get notified of a new security hole at no charge to them and the iDefense customers will start silently asking the vendor to fix the problem.

ZeroDayInitiative/3com (Terri Forslof, Manager of Security Response): The art of Full Disclosure helps some, but not all. Because the general population does not follow public security lists such as BugTraq and Full Disclosure, I strongly encourage all independent researchers (and those belonging to organizations as well!) to follow a practice of responsible disclosure. In the old days, that used to imply that the researcher should make every attempt to contact the vendor directly and keep the information confidential until the vendor could issue an update to protect their customers. While that model still works, and is still a great altruistic idea, some researchers seem to have grown tired over the years of the often long battle to get vendors to take them seriously, and fix the vulnerability.

Finding vulnerabilities takes a special skill set, and time. In the modern age, this translates into a marketable talent. I encourage researchers who don't want to deal with the hassle of working with the vendor to utilize the Zero Day Initiative program - which offers them fair compensation for their work, while still providing a vendor the advantage of time to develop a solution to the problem and ship an update to their customers. Because we handle the communications with the vendor, and work with them to address the problem, the researcher can then move onto working on their next project. In the meantime, we are able to deliver protection to our customer's against that vulnerability via our TippingPoint IPS device. We always assume that if one person has discovered a vulnerability, then it's likely that another out there somewhere has discovered it as well. Our customers enjoy the peace of mind in knowing that they are protected during that time when the vendor is working to deliver the update.

Of course, once the problem has been addressed, I'm an advocate of making as much noise as possible that there was a problem, and that there is a solution. If you don't spread the word, then the general population won't hear about the issue. It's not a perfect solution - nothing is. All vulnerabilities are not created equal, and not all products have the same impact on society - but as the world of security research evolves, I think that we as security vendors need to evolve right along with it, and continue to look for innovative ways to get vulnerabilities out of the wild, and into the hands of the vendors who can fix them.

Part 3: Prominent researchers discuss the disclosure process

SF: When you find an exploitable vulnerability, what makes you choose the type of disclosure process (if any)?

David Litchfield: I see there being two reasons for disclosure; firstly when a vendor is not taking responsibility for their product and they are not going to issue a patch or are wasting time in delivering a patch. I'm all for giving a vendor as much time as they need to fix the flaw providing they are making a best endeavor effort to fix the flaw. If however the vendor is wasting time and unnecessarily leaving their customers exposed to risk then disclosure should be threatened once all else fails. The second reason for disclosure is for education. It's important that others can see where mistakes are being made so they can avoid the same issues. As there is no real pressure to disclose for educational reasons, I and NGS put a post-patch three month embargo on the details of the flaws we find. This gives time for the patch to be installed before the details are made public.

H D Moore: It depends on how the vulnerability was found, who else knows about it, what the impact of the vulnerability is, and whether the vendor has a history of being responsive. The vendor is notified in nearly every case, with the exceptions being low-risk denial of service or information disclosure flaws. I usually wait until I have working exploit code before notifying the vendor, since an exploit makes it easier for the vendor to reproduce the flaw and prioritize patch development.

If another researcher was involved in the discovery of the bug, the disclosure process also depends on their personal views and the policies of their employer. A great example of this is the recent Windows Mailslot vulnerability (MS06-035). Pedram Amini and I found this issue while working on a related problem, and his employer (TippingPoint) determined the disclosure process and timeline. I agreed to wait a period of time after the patch was available before releasing the exploit code.

For bugs I find on my own, the disclosure timeline depends on the impact of the vulnerability and the response from the vendor. While investigating the recent RASMAN vulnerabilities (MS06-25), I stumbled across another flaw that was not patched and resulted in a crash of the svchost.exe that contains other critical services. This bug requires valid authentication credentials and results in a forced reboot in the most severe case. Microsoft was notified and they decided it would not be addressed until the next major service pack. An exploit module capable of triggering a crash in svchost.exe has been included in the 3.0 Beta 1 of the [Metasploit] Framework.

There have been a few cases where the vendor silently patched a flaw before I had a chance to finish the exploit code or report it. The Quicktime application shipped with Mac OS X contained a format string flaw that could be triggered through the Safari web browser. It was possible to trigger an arbitrary memory write by redirecting the user to a quicktime:// URL containing format specifiers. I considered the bug a low priority and never finished the exploit or notified Apple. Sometime in the last couple of months, the bug was silently patched in a security update.

Michal Zalewski: I do believe in disclosure, particularly when the issue at hand is in some way interesting, unique, or may contribute to our understanding of software security. It's good to share. Because of this, I almost always disclose my research, with the exception of issues too trivial and too limited to warrant any public attention. I'm glad I can afford this luxury.

I'm also a believer in full and swift disclosure. This is not to say I want to arm cyber-hooligans - that's unnecessary: they seem to do better and better despite creeping limits and delays in vulnerability disclosure. By the way, some experts argue it's a good thing: kids' annoying and disruptive pranks have the side effect of raising awareness and improving defenses, to a point where a global disaster is unlikely; weren't it for what we learned since 1995 or so, a lone malicious fellow with an agenda could bring our economy to a grinding halt. Around that year, the infrastructure was vulnerable to so many awfully obvious flaws (look at the exploits back then!)... in 1995, we didn't depend on the Internet that much, of course, but would vendors improve the security of their products in any way without ten years of full disclosure? Or would every single service go down in flames after receiving a single command with more than 255 bytes of text?

In any case - what I want to achieve is give the customer and open-source security vendors equal chances. They need information, even if certain vendors led us to believe otherwise.

I see no harm in giving the vendor a fair chance to comment on the problem (this is often beneficial for me, as well) and provide a fix to any immediately exploitable vulnerability. This is why I usually give the vendor an advance notice, and am willing to wait for a week or two if they're responsive and friendly. The most important exception is dealing with a vendor who's either speaking or acting against disclosure of security flaws altogether, or is routinely abusing the "grace period" granted by researchers to unreasonably delay fixing of reported problems.

It is argued that such an early disclosure renders users vulnerable to attacks, but in reality, they were vulnerable all the time - only now, they know about it, the security software developers know about it - and all the concerned parties and may convince the vendor to implement proactive security measures, and cooperate with the infosec community.

I do not claim this to be a morally superior way of handling disclosure; it's simply how I'm doing it, what I believe in, and I sure hope my kids would live in a society where it is acceptable to openly discuss the failure modes of technologies we depend on.