What to Expect After Contacting the Vendor

Communication is key. As you might suspect, the vendor will not be thrilled if you proceed to tell everyone about the bug immediately after contacting them. As mentioned earlier, it is generally accepted that the software vendor should be notified prior to when you disclose the security issue to others, but how long of an advance notice should be given? The first well-documented policy that answers questions in this area is the RFPolicy ( http://www.wiretrip.net/rfp/policy.html ). In June 2000, a security researcher named Rain Forest Puppy created this policy in response to reactions from vendors when he publicly disclosed issues before a fix was available. Some vendors felt that they weren t given adequate chance to fix the problem or that there was an unwritten rule around the amount of time before public disclosure. RFPolicy sets up basic guidelines for finders to notify vendors and work with them so that the bug can be fixed.

In July 2003, similar but more detailed and complex guidelines were created by the Organization for Internet Safety (OIS) in a document titled Guidelines for Security Vulnerability Reporting and Response ( http://www.oisafety.org/guidelines/secresp.html ). OIS is composed of both software and security companies, with members such as Oracle, Microsoft, Internet Security Systems, McAfee, and Symantec. Many people don t follow the guidelines of either policy word for word but have accepted the general theme that vendors should be notified prior to any public disclosure and that vendors and bug finders should communicate clearly about the issue.

Vendors typically respond quickly and confirm receipt of the issue and then work on reproducing the issue reported. During this time, members of the vendor team might ask you for additional information so that they can better understand the issue. More details about what the vendor should do after a bug is reported are included in the section titled Addressing Security Bugs in Your Product later in this chapter.

Dealing with Unresponsive Vendors

What should finders do if the vendor isn t responding? Finders should verify they are contacting the right people and try alternative methods of communication. If e-mail was sent to a general support address, the recipient might not understand what to do with the message. If the vendor doesn t respond through e-mail, a phone call might work better.

For example, a friend of ours was having difficulty contacting a vendor through e-mail, so he phoned the company. When the vendor s switchboard operator asked who to connect him with, he asked for someone working on software security. The operator didn t know who to contact, so our friend asked for the public relations department. The PR department understood the importance of the issue and within a few hours our friend received a response from someone working on the product s security.

If the vendor continues to be unresponsive or doesn t seem to take the issue seriously, third parties such as the Computer Emergency response Team (CERT) ( http://www.cert.org/ ) can help report the issue to the vendor. CERT often has existing relationships with companies, usually knows the best place to report vulnerabilities, and can always figure out where to go. CERT can help the finder remain anonymous or provide the vendor with the finder s contact information to ensure proper credit is given.

Vendors should take great care to address security bug issues properly. This is discussed more in the section titled Addressing Security Bugs in Your Product later in this chapter.

Note  

Selling vulnerability details is a current hot topic in the security testing field. Currently, two companies (iDefense and the Zero Day Initiative which is run by TippingPoint, a division of 3Com) pay bug hunters for previously undisclosed vulnerabilities. These companies submit the vulnerability details to the vendor and do not publicly disclose the details until a patch is released. iDefense notifies its customers about the issue prior to when a fix is released through a subscriber-only list. TippingPoint uses the bug information to build a stronger intrusion detection system that will guard against the attack. The sale of vulnerability details causes some concern because it encourages legitimate bug hunters to disclose details to an entity other than the vendor. On the other hand, the companies that buy the vulnerabilities argue that they help get the bug fixed by disclosing it to the vendor and that they give a bug hunter who might immediately disclose the issue to the public or sell the details to an unscrupulous party an incentive not to do so.