Corelan Vulnerability Disclosure Policy

This document describes the security vulnerability disclosure policy of Corelan Team.

It is the official policy of Corelan Team members ("us") to exercise the responsible disclosure of security vulnerabilities in a manner which is of maximum value to all affected parties. The Corelan Team policy is based on RFPolicy guidelines. Corelan reserves the right to change this policy at any time, without prior notice.

The permalink URL for this policy is http://www.corelan.be:8800/index.php/disclosure-policy.

Executive overview for vendors and software maintainers

This policy states the ‘guidelines’ that Corelan Team intends to follow. You basically have 7 days (read below for the definitions and semantics of what is considered a ‘day’) to return contact to the Corelan Team, and must keep in contact with us at least every 14 days. Failure to do so will discourage us from working with you and encourage Corelan to publicly disclose the security problem.
This policy is not set in stone–in fact, it is encouraged that all parties regularly communicate with each during the process, adjusting as situations arise.

Legal stuff

If you believe that disclosing the details about a given vulnerability would be illegal, you have to mention this specifically. The fact that we report a vulnerability does not mean that we have used the application ourself or that we have broken some EULA. So if you believe we are breaking laws or agreements just by reporting this issue to you, you will have to tell us explicitly, in your first response after we have reported something to you (within 7 working days). That also means that you agree not to take any steps against us, ever. After all, we only want to help you and tell you about an issue so you can get it fixed.

Basically, if you have received a vulnerability report from us, there are 2 options :

You want to work with us. You automatically promise and agree to never take any steps against us. If that is not the case, you have to mention this explicitly, in your first communication with us, within the first 7 working days after we have reported something to you. In that case, you automatically agree to give us the chance to step out of the process without any consequences whatsoever. If you did not mention this, you automatically agree not to take any steps either.
You don’t want to work with us. You have to explicitly mention that you don’t want to work with us. If you did not mention this, we will assume that you ignored our offer to cooperate, and that also means that you refrain from taking any steps against us ever. If you don’t want to work with us, your only option is to ask us not to make the details public. Obviously, we cannot stop anyone else from finding the same vulnerability and make it public. So if that happens, we cannot and will not be held responsible for that, or for any damages it may cause. In other words, you cannot take any steps against us either (so perhaps you should consider option 1 again)

It is clear that our intentions are sincere. We don’t want to harm you or any of your customers. We don’t want anyone to hack your software or systems, or break into systems using vulnerabilities in your software/systems. We don’t want to damage you. You automatically agree that this is the case. So anything that gets published (even if that includes code that would allow malicious people to hack into applications or systems) as a result of this disclosure process, is done from an educational point of view. You cannot ever hold us responsible for that or for any damage this may cause.

Conclusion: the fact that we reported something to you, means that we want to help you. So you automatically agree that you will never take any steps against us. If you want to take steps against us, you have to explicitly mention this in your first communication back to us, and you automatically give us the option to step out of the process without any consequences. More information on timings linked to this "first communication" can be found below.

Purpose of this policy
Policy definitions
Policy
Detailed/commented explanation of policy
Policy FAQ
Using this policy

Purpose of this policy

This policy exists to establish a guideline for interaction between a researcher and software maintainer. It serves to quash assumptions and clearly define intentions, so that both parties may immediately and effectively gauge the problem, produce a solution, and disclose the vulnerability.
First and foremost, a wake-up call to the software maintainer: the researcher has chosen to NOT immediately disclose the problem, but rather make an effort to work with you. This is a choice they did not have to make, and a choice that hopefully you will respect and accept accordingly.

The goal of following this policy, above all else, is education:

Education of the vendor to the problem (ISSUE, as defined below).
Education of the researcher on how the vendor intends to fix the problem, and what caveats might cause a solution to be delayed.
Education of the community of the problem, and hopefully a resolution.

With education, through continued communication between the researcher and software maintainer, it allows both parties to see where the other one is coming from. Coupled with compensation*, the experience is then beneficial to the researcher, vendor, and community. Win/win/win for everybody. :)

(* Compensation is meant to include credit for discovery of the ISSUE, and perhaps in some cases, encouragement from the vendor to continue research, which might include product updates, premier technical subscriptions, etc.

Monetary compensation, or any situation that could be misconstrued as extortion, is highly discouraged.

Policy definitions

The ISSUE is the vulnerability, problem, or otherwise reason for contact and communication.
The ORIGINATOR is the individual or group submitting the ISSUE.
The MAINTAINER is the individual, group, or vendor that maintains the software, hardware, or resources that are related to the ISSUE.
The DATE OF CONTACT is the point in time when the ORIGINATOR contacts the MAINTAINER.
All dates, times, and time zones are relative to the ORIGINATOR.
A work day is generally defined in respect to the ORIGINATOR.

Policy

A. The ORIGINATOR will send email regarding the ISSUE to the MAINTAINER; the point in time when email is sent from the ORIGINATOR is considered the DATE OF CONTACT.
It is important that the ORIGINATOR review any documentation included with the object of the ISSUE for indication of a proper method of contact. That failing, the ORIGINATOR should check the web site of the MAINTAINER for methods of contact. Should the ORIGINATOR not be able to locate a suitable email address for the MAINTAINER, the ORIGINATOR should address the ISSUE to:

regardless of their existence.

Anyone who could be deemed as a ‘MAINTAINER’ is encouraged to populate at least some of the above email addresses. Email auto-responses should not be considered as a message from the MAINTAINER.
Addressing the ISSUE to the above listed email addresses may cause the email to be received by non-authoritative persons (for example, to an online service provider who happens to have an user named ’security-alert’).

B. The MAINTAINER is to be given 7 working days (in respects to the ORIGINATOR) from the DATE OF CONTACT; should no contact occur by the end of 7 working days, the ORIGINATOR should disclose the ISSUE. Should the MAINTAINER contact the ORIGINATOR within the 7 working days, it is at the discretion of the ORIGINATOR to delay disclosure past 7 working days. The decision to delay should be passed upon active communication between the ORIGINATOR and MAINTAINER. If the disclosure process (and anything that follows this process) can trigger the MAINTAINER to take legal steps against the ORIGINATOR, the MAINTAINER has to explicitly mention this in this first contact, and will automatically give the ORIGINATOR the chance to step out of the process without legal or other consequences.

C. Requests from the MAINTAINER for help in reproducing problems or for additional information should be honored by the ORIGINATOR. The ORIGINATOR is encouraged to delay disclosure of the ISSUE if the MAINTAINER provides feasible reasons for requiring so.

D. If the MAINTAINER goes beyond 7 working days without any communication to the ORIGINATOR, or if the MAINTAINER does not consider the reported vulnerability to be an issue, the ORIGINATOR may choose to disclose the ISSUE. At that point, the MAINTAINER automatically agrees not to take any steps against the ORIGINATOR. The MAINTAINER is responsible for providing regular status updates (regarding the resolution of the ISSUE) at least once every 14 working days, unless MAINTAINER and ORIGINATOR have agreed upon a different update frequency.

E. In respect for the ORIGINATOR following this policy, the MAINTAINER is encouraged to provide proper credit to the ORIGINATOR for doing so. Failure to document credit to the ORIGINATOR may leave the ORIGINATOR unwilling to follow this policy with the same MAINTAINER on future issues, at the ORIGINATOR’s discretion. Suggested (minimal) credit would be:

"Credit to [ORIGINATOR], a member of Corelan Team, for disclosing the problem to [MAINTAINER] and working with us to protect our customers."

F. The MAINTAINER is encouraged to coordinate a joint public release/disclosure with the ORIGINATOR, so that advisories of problem and resolution can be made available together. The MAINTAINER must communicate a final resolution date for fixing the ISSUE within the first 14 working days after the ISSUE was reported to the MAINTAINER. This deadline must be set to a date that is not beyond one calendar year after the ISSUE was reported to the MAINTAINER. The MAINTAINER is allowed to postpone this deadline only once, with a maximum of one calendar month. If the issue is still not resolved after the second deadline date, the ORIGINATOR may choose to publicly disclose the vulnerability.

By participating in the vulnerability disclosure process, the MAINTAINER agrees that the ORIGINATOR is allowed to publicly disclose the vulnerability details without any legal consequences.

G. If the ISSUE is publicly disclosed, by a third-party, the ORIGINATOR is encouraged to discuss the current status of the ISSUE with the MAINTAINER; based on that discussion, the ORIGINATOR may choose to disclose the ISSUE. The MAINTAINER is encouraged to credit the ORIGINATOR for discovering the ISSUE. Should the MAINTAINER disclose the ISSUE, or items supporting/relating to the ISSUE (patches, fixes, etc), the ORIGINATOR may choose to disclose the ISSUE.

Detailed/commented explanation of policy

This section serves to elaborate on the items in the policy, for better understanding.

A. Pretty self explanatory–the ORIGINATOR is to email the MAINTAINER about the problem. The ORIGINATOR should do their homework and try to find the correct address to email (by checking the MAINTAINER’s web site, by looking in documentation distributed with the software/product, etc). Emailing InterNIC handles or addresses such as ‘postmaster’ or ‘webmaster’ is not good, since they are most likely IT support staff and not the proper representatives to handle such a situation.

B. The MAINTAINER has 5 work days to respond (with a maximum of 7 calendar days). Note that all times of work days are relative to the ORIGINATOR, not the MAINTAINER. Suggestion to the MAINTAINER: sooner is better than later–just because you have 5 days does not mean you need to take them all. The ORIGINATOR is technically free to do whatever they want to do after 5 work days–however, they should be fair and wait if the MAINTAINER shows adequate initiative to fix the ISSUE.

C. Just as the MAINTAINER shouldn’t ignore the ORIGINATOR, neither should the ORIGINATOR ignore the MAINTAINER. The ORIGINATOR should help the MAINTAINER recreate the problem, if necessary. It’s probably in the best interest of the ORIGINATOR to help the MAINTAINER confirm the problem–otherwise, the ORIGINATOR stands to disclose a potentially false ISSUE.

D. The MAINTAINER has to actively give status reports. Note that it’s the MAINTAINER’s responsibility to do so, and not the ORIGINATOR’s responsibility to request them.

E. If the ORIGINATOR does indeed take the time to follow this policy, they should be acknowledged not only for doing so, but in general, acknowledged for finding the problem. There are proper ways to cite references, credit sources, and otherwise respect the origination of information–I suggest vendors do the same. If you can not respect the ORIGINATOR enough for taking the time to notify you of the ISSUE, the ORIGINATOR (and possibly others) may feel reluctant to follow this policy with the same MAINTAINER in the future.

F. Making the problem and solution advisories available together allows the community to have immediate access to both the problem description and the appropriate fix.

G. If the MAINTAINER feels it’s appropriate to alert the public of the issue, then there’s no reason why the ORIGINATOR should not. Traditionally, alerting the community of a problem (but not providing full exploit details) has proven to be futile; other researchers are then just as likely to discover the problem as well–and they may not bide by the guidelines set by this policy. Therefore, if the issue is to be disclosed, all aspects of it should be disclosed. If a third-party discovers and publishes the vulnerability, the MAINTAINER and ORIGINATOR should evaluate the status of a fix, and act accordingly. No matter what, the MAINTAINER should always credit the ORIGINATOR.

H. After the initial communication between ORIGINATOR and MAINTAINER has been established (so basically if the MAINTAINER accepts this policy and wants to work with the MAINTAINER to get the issue fixed), the MAINTAINER is required to provide the ORIGINATOR with a “patch window”. This is the time the ORIGINATOR needs to get the issue fixed. By default, the maximum acceptable patch window is 6 months, starting from the date the issue was reported to the MAINTAINER. This means that, if the MAINTAINER does not negotiate a larger patch window, the ORIGINATOR is allowed to disclose the details about the vulnerability in public after 6 months.

I. The MAINTAINER is requested to pro-actively provide status updates to the ORIGINATOR, on a regular basis. The default frequency of providing updates is once per week. The MAINTAINER can negotiate a different frequency, but must do so within the first 7 days after the initial communication has been established. If the MAINTAINER fails to provide status updates twice, then the ORIGINATOR is allowed to go public at any time.

Policy FAQ

Q. This policy uses dates and times for gauging responses. How do time zones/holidays/weekends/cultural differences factor in?
A. First off, as noted above, all dates and times are relative to the ORIGINATOR. Now, it is quite possible that a difference in date/time perspective occurs, due to: the ORIGINATOR being on a different continent than the MAINTAINER, the MAINTAINER having a different work week than the ORIGINATOR, the MAINTAINER being sick, the MAINTAINER taking an extended weekend, the MAINTAINER having a holiday, etc. Therefore the initial contact period was extended to 7 days–we feel that 7 days should be adequate to surmount any date/time differences.

Q. I’m a software maintainer, and I can’t possibly fix the problem in 5 or 7 days….
A. You don’t have to. If you (re)read the above, you have 7 calendar days to establish communication. Provided you cooperate with the researcher and keep them ‘in the loop’, they should provide you with whatever time necessary to resolve the ISSUE (within fair reason).

Q. I’m a software maintainer, and I want more than 7 days!
A. Well, considering that, in general, you don’t have *anything* technically, this document hopes to provide you with at least 7. Be on your best behavior, cooperate with the ORIGINATOR, and you may get more.

Q. You mention compensation–do ORIGINATORs expect to be paid?
A. NO! (Well, they shouldn’t…I can’t definitely predict the expectations of people) Compensation, as mentioned in this policy, is meant first-and-foremost to be PROPER CREDIT. Academia has historically and religiously provided credit when referencing all types of works and research; the ISSUE provided by the ORIGINATOR should also be thought of as research, and the ORIGINATOR should be credited accordingly. Now, beyond that, it may be in the vendor’s best interest to promote good relations with the researcher, and one suggested way is to provide updates and product licenses. A lot of research is done on evaluation and trial versions of software–providing a single, full license/copy should produce little impact on the vendor, but greatly help the researcher. Another suggestion is to allow access to support sites/technical content.

Contact

If you have any questions about this policy, please contact vulnerability-disclosure@corelan.be

Peter Van Eeckhoutte's Blog