Contacting the Vendor | Hunting Security Bugs

Before contacting the vendor, verify that your issue is a bona fide security issue. Issues listed in the 10 Immutable Laws of Security ( http://www.microsoft.com/technet/archive/community/ columns /security/ essays /10imlaws.mspx ) are commonly reported to Microsoft but are not considered to be vulnerabilities. When reporting a security bug, ideally you should provide the vendor with the following information:

Type of issue, for example, buffer overflow, SQL injection, cross-site scripting.
Software product and version that contains the bug.
Which service packs , security updates, or other updates for the product have been installed.
Clear steps to reproduce the issue. If possible, attempt to reproduce the issue on another computer to ensure the vendor will be able to reproduce the issue based on the information you report to them.
Proof-of-concept code is helpful to the vendor.
Any special configuration required for the issue to be reproduced.
Impact of the issue, including how an attacker could exploit the issue.

After you gather the necessary information, quickly contact people at the vendor who can properly handle the issue. Many vendors provide information on their Web sites about how to report a security vulnerability. For example, to report a security vulnerability to Microsoft, you can send mail to secure@microsoft.com. If contact information isn t available, try sending e-mail to the following addresses:

Secure@[ vendor_domain ]
Security@[ vendor_domain ]
Security-alert@[ vendor_domain ]
Secalert@[ vendor_domain ]

Important

If you are reporting a security bug, remember you are sending the vendor sensitive information over the Internet. You should take precautions to protect the details of the vulnerability. Many vendors have a Pretty Good Privacy (PGP) key, Secure/Multipurpose Internet Mail Extensions (S/MIME) certificate, or Secure Sockets Layer (SSL) Web form that can be used to help protect the information from prying eyes.

When we haven t been able to find information about how to report a vulnerability on a company s Web site, we usually write a short note stating that we found a vulnerability and asking who the right person to contact about the issue is and send it to the preceding addresses. This practice almost always results in a quick response that includes the e-mail address of the vendor s security investigation person or team. If you re still having trouble contacting a vendor, try e-mailing the Bugtraq ( http://www.securityfocus.com/archive/1 ) and Full-Disclosure ( https ://lists.grok.org.uk/mailman/listinfo/full-disclosure ) mailing lists to see whether anyone knows a security contact for the vendor of interest; avoid revealing any details of the bug or the product containing it when contacting the mailing lists. The sooner you report the issue to the vendor, the sooner the vendor can begin working on understanding and fixing the issue.

Tips on reporting bugs internally

This chapter focuses on reporting bugs found in another company s software. The process of reporting security bugs found internally in your company s applications is different. Following are steps to use to report security bugs in your own company:

Have clear steps to reproduce the issue.
Do not exaggerate the issue. Not all security bugs are equal in severity. It is important to represent the impact of the issue accurately.
Do not assume the programmer is aware of the security issue unless you know for sure the programmer already knows about the problem. Include enough details in your report so that a programmer can take action, or talk with the programmers about the general security problem. For example, don t enter a bug that says, ActiveX control allows repurposing through the Load method if the developer isn t aware that ActiveX repurposing attacks exist (see Chapter 18, ActiveX Repurposing Attacks, for more information about such attacks). The person who will fix the bug often is the same person who wrote the original code and introduced the flaw.

Get involved in the root cause analysis with the programmer. This enables you to better understand the product s code and enables the programmer to better understand your security concerns. The flaw might exist because the programmer doesn t understand the current design, or perhaps the implementation is a security problem.