Corelan Vulnerability Disclosure Policy

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

It is the official policy of Corelan Team members (referred to as “us” or “we” hereafter) to exercise the responsible/coordinated disclosure of security vulnerabilities in a manner which is of maximum value to all affected parties. Corelan reserves the right to change this policy at any time, without prior notice.

Current version : v1.7, last changed on april 29, 2011, 10:26 Brussels time : added link to attrition

Older versions :

1.6, last changed on july 26th, 2010, 11:26 Brussels time : introduced “coordinated” in conjunction with “responsible”.
1.5, last changed on july 13th, 2010, 7:24 Brussels time : added section “Communication Guidelines”
1.4, last changed on july 11th 2010, 16:53 Brussels time : added a statement about “upcoming advisories”.
1.3, last changed on april 18th 2010, 11:30 GMT+1
1.2, last changed on april 12th, 2010, 15:07 GMT+1

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

Executive overview for vendors and software maintainers

This policy states the ‘guidelines’ that Corelan Team intends to follow.

First of all, Corelan has nothing but good intentions. We want to report a bug in your application, and we want to have the freedom to make details about the bug publicly available after you have fixed the bug, or if you ignored our report, or if you decide not to work with us. We assume that none of these actions are illegal, unless you specify otherwise (and can prove that it is).

The idea behind this policy is to define some agreements in terms of timings and procedures, and to express our good intentions to you. At the same time, we like you to approach this in a positive and constructive way.

Legal stuff

If you believe (and can prove) that disclosing the details about a given vulnerability in your application is illegal, you have to mention this specifically and provide us with that proof.

Just keep in mind that

we did not obtain the application/software in an illegal way.
we did not compromise remote/3rd party systems nor want anyone else to do so
we do not support or advertise illegal activities, and we don’t want anyone to use the information we provide on the internet for illegal activities
we strongly believe in freedom of speech
we want to keep the community informed and want to publish the results of our research

So if you believe we are breaking laws or agreements by finding a bug/vulnerability or by reporting this bug/vulnerability to you, or to the public, you will have to tell us explicitly in your first response after we have reported something to you (within 7 working days).

After all, at this point we only want to report a bug/vulnerability in your application and we believe it is fair to state that reporting or exposing details about a bug is not illegal.

Keep in mind that bugs/vulnerabilities are disclosed every day. A good amount of these disclosures are not the result of a responsible/coordinated disclosure process. So the fact that we have contacted you means that we want to work with you and don’t want to cause any damage. We believe, from a commercial point of view, it makes sense for you to get the opportunity to fix the bug before we publish the details.

Tip : If your intent is to issuing legal threats to us, then it might be important to know that there are journalists that cover these types of stories.

Workflow

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

You want to work with us. We will work with you to identify the vulnerable code and allow you the time to fix it. When the code is fixed and made available to customers/end users, we will publish details about the bug. All of this happens in a coordinated way.
You don’t want to work with us. That’s fine too. We cannot force you to work with us. If you decline or ignore our help, we will assume that you don’t want our help and don’t want us to give you time to fix the bug. This does not mean that we have bad intentions and want to do harm to anyone. Despite your decision to decline our help, we feel it is important to make the details about the bug public. After all, this can help other people to take measures in order to avoid issues when someone with bad intentions discovers the same bug and decides to abuse it without telling anyone. Obviously, if that happens, we cannot be held responsible for that, or for any damages it may cause.

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. We only want to help you fix a possible dangerous bug in your application, and disclose the details about the bug/vulnerability after you have fixed it, so others can learn from it as well. (Obviously, if you decline to work with us, we’ll still make the vulnerability public, because we want others to be able to protect themselves and learn from the vulnerability)

Anything that gets published (even if that includes code that would allow malicious people to compromise applications or systems) that is directly or indirectly related this particular bug, is done from an awareness and educational point of view. We don’t want to people to do harm, but we still want to indicate how serious a certain bug is (awareness) so we might have to demonstrate that “any” arbitrary code can be executed by exploiting the bug/vulnerability. Again, this is only done from an awareness point of view.

We assume that disclosing the details of the vulnerability we have found is not illegal in any way.

Conclusion: the fact that we reported something to you, means that we want to help you. If you don’t agree with our policy and/or want to take legal actions against us, you have to explicitly mention this in your first communication back to us.

Keep in mind that this might not stop us from making the bug public, including a note that you declined our offer to work with you.

Also, right after we have sent you a vulnerability report, we might publish information about the communication between you and Corelan team in an “upcoming advisories” table. The information that will be made public in the upcoming advisories table is specifically chosen, to avoid that other people would be able to figure out the exact details about the vulnerability, and would not have been able to do so, in any way, if they would not have seen the table entry. In most cases, only the vendor name and/or product name will be shown.

Purpose of this policy
Policy definitions
Policy
Detailed/commented explanation of policy
Communication guidelines
Policy FAQ

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. If the MAINTAINER chooses to work with the ORIGINATOR, the MAINTAINER is responsible for providing regular status updates (regarding the resolution of the ISSUE) at least once every 14 calendar days, unless MAINTAINER and ORIGINATOR have agreed upon a different update frequency. It is the responsability of the MAINTAINER to negotiate a new update frequency within the first 14 calendar days.

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. It is clear that the ORIGINATOR wants to allow the MAINTAINER to make the resolution available prior to the disclosure of the problem. 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.

In any way, the ORIGINATOR believes there is nothing illegal about publicly disclosing a bug.

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 7 work days to respond (with a maximum of 9 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 7 days does not mean you need to take them all. The ORIGINATOR is technically free to do whatever they want to do after 7 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. The default frequency of providing updates is every 14 calendar days. 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.

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. After the initial communication between ORIGINATOR and MAINTAINER has been established (so basically if the MAINTAINER accepts the offer to work with the ORIGINATOR and thus accepts this policy), 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 one year, 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 one year months.

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.

Communication guidelines

All email communication from MAINTAINER to ORIGINATOR must be sent to security@corelan.be. All email communication from ORIGINATOR to MAINTAINER will be sent from security@corelan.be. Emails from ORIGINATOR to MAINTAINER, not sent from security@corelan.be, should be considered invalid/fake and must be ignored.

If you believe it is important to sign or encrypt email communications, then you have to explicitely state this, and send your public PGP/GPG key to security@corelan.be. The public key for security@corelan.be can be downloaded here.

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 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

Corelan Cybersecurity Research

:: Knowledge is not an object, it's a flow ::