HackLabs' Disclosure Policy
HackLabs believes that a coordinated disclosure is the best approach to properly and efficiently address a vulnerability and thus protect a vendor's customers. However, software vendors often fail to respond to vulnerability reports or simply take too long to develop fixes thus leaving their customers exposed for an irresponsibly long period of time.
HackLabs has decided upon the following disclosure policy, which we find to be a reasonable "match" between a fair amount of engineering and QA efforts and the need of providing a timely fix to secure security vulnerabilities.
Throughout this document, "vendor" is either as the producer, seller, developer or maintainer of the software/hardware/system etc. - or generally speaking, organisation or person responsible for correcting the identified vulnerability.
When HackLabs discovers a security vulnerability in a system The vulnerability is analysed to point at where it can be reasonably reproduced. It is then documented in a Vendor Vulnerability Advisory.
Vendor Vulnerability Advisory
Contains (when possible):
1. detailed description of the problem,
2. demonstration of the problem,
3. possible scenario(s) of its exploitation and
4. recommendation(s) for vendor's actions.
The private report is classified as strictly confidential and not made public.
Our activities are then governed by the following priorities:
1. Security of our customers
2. Security of global community
3. Fair vendor treatment
When completed, we send the Vendor Vulnerability Advisory to the vendor. When the discovered security problem affects our customers and we have a solution (fix or workaround), we notify them and provide recommendations for protecting their systems.
- If no security contact is known for the vendor, an e-mail requesting the security contact e-mail address may initially be sent to certain public e-mail addresses associated with the vendor.
- When a security contact or other relevant e-mail address has been identified, a vendor initially receives a mail with vulnerability details along with a preset disclosure date (usually set to four weeks later).
- If the vendor does not respond to the initial mail within a week, it is resent.
- If no response has been received at the day of the preset disclosure date, the vulnerability information is published immediately without further coordination attempts. Assuming that it meet the criteria specified by HackLabs in this policy.
- If the vendor responds to either the initial mail or the resent mail, a new disclosure date may be set in case the vendor cannot meet the preset date.
- HackLabs expects to receive continuous status updates from the vendor. If none are provided by default, the vendor will be contacted about once a month with a status update request.
- Should a vendor not respond to a status update request, it is resent a week later
- Should the vendor not respond to two consecutive status update requests, a mail is sent to the vendor advising that the vulnerability information will be disclosed a week later if no response is received. Has no response been received by this date, the vulnerability information is immediately published without further coordination attempts.
- Eventually, the vulnerability information will be published by HackLabs when:
a) The preset/agreed disclosure date is reached.
b) The vendor issues a fix and/or security advisory.
c) Information about the same vulnerability is published by a third party.
d) 6 months from the initial contact date has passed.
Helping the vendor
We're willing to assist the vendor (within reason) effort to help them reproduce the vulnerability and find an effective solution for it. When the vendor provides a fix, we are prepared to test it in our lab.
In case the vendor wants to publish his own security bulletin about this vulnerability (the usual method of informing users of fix availability), we are prepared to review this bulletin for technical accuracy before it is published. And would request a joint release and appropriate acknowledgement in the vendors advisory.
The Public version of the advisory differs from private one in that it doesn't include additional details and notes designed for the vendor.
When the vendor has corrected the problem and/or made the solution available, we distribute the public report to the general public. This is done by:
1. sending it via e-mail to our affected customers,
2. including the public report in our Advisories page,
3. sending it via e-mail to subscribers of the HackLabs Mailing List and
4. sending it via e-mail to security mailing lists.
Exception to this are reports about security vulnerabilities that would in our opinion provide no significant benefit to the general community (e.g. a trivial vulnerability in some site which has already been fixed). We don't publish these reports, but we may name them in our Advisories page,
We may give the vendor an opportunity to review the public report before we publish it.
Sometimes the notified vendor is very responsive and cooperative, while other times we get absolutely no response even after several weeks of trying to establish a contact. Regardless of this, our actions are governed by the Priorities stated above. Therefore if we find a vulnerability in a public site, but the owner neither responds nor fixes the problem. In such cases, if we decide that publishing our public report would do more harm to our customers or global community than it would benefit them, we only list the advisory on our Advisories page, mark the vendor as "No Response" and continue to establish contact.
However, when we believe that such a security vulnerability presents a real threat to the global community, and it seems that publishing is the only way for pushing the vendor into fixing the problem, we do publish the public advisory, As long as publishing would be in accordance with the Priorities stated above. The same rule applies when the vendor doesn't exist any more or doesn't support the affected system any more.
Language and Format
Private reports are written in English or in vendor's local language where possible and are in HTML or PDF format. Public reports are written in English and are in ASCII format for reasons of general understanding and readability.
Our reports are copyrighted because we time and effort in analysing and documenting the vulnerabilities they describe.