Coordinated Vulnerability Disclosure
This is an informal info dump on how to perform coordinated vulnerability disclosures. Read Vulnerability Jargon first.
Cheers and greetz to Seth Arnold, Marc Deslauriers, and Tobias Heider.
1. Receiving a Vulnerability Report
Coordinated vulnerability disclosure (CVD) is all about communication. As a coordinator, you may not work directly on fixing a vulnerability. You will be communicating between different groups, possibly to: the reporter, discoverer, remediatior, affected downstreams, other vendors, media, etc.
Mindset
If you are receiving a vulnerability report from an external party, they are communicating that there is a security issue affecting users and they want it solved. They may want other things also, but the shared concern is user safety. The discoverer has the right to disclose their work however they choose. They are choosing to protect users by working with the software maintainers. The first thing a coordinator should tell a vulnerability reporter is Thank you! This relationship is important and the reporters labor must be respected. Coordinators can demonstrate respect by being timely, setting clear expectations, and following-up.
For instance, if you receive a report you should triage it quickly and then acknowledge the report. If you agree that the issue is a vulnerability, take it seriously and reserve a CVE to share with the reporter as soon as possible. Tell them that they will be attributed for their discovery. If your team needs time triage or develop a patch, share this with the reporter and clearly state when the reporter can expect an update from you. Give them a date and follow-up appropriately. If possible, give them a patch development timeline and/or set a Coordinated Release Date (CRD). If you are not engaged in bidirectional communication the reporter will know this and the relationship may deteriorate. Keep reporters in the loop and demonstrate that this is important through action.
The same mindset applies to internal reports. Internal developers want to protect users and are seeking your guidance. Some developers want clear decisive decisions from coordinators, while others may want to help weigh in more. Read the situation and communicate.
Initial contact
After thanking the reporter, address the report. If you have triaged the report, share your findings. If it is a vulnerability, assign a CVE to share. CVE assignment is a clear signal that you take the vulnerability seriously. Ask how the reporter(s) want to be attributed when the CVE and possible announcement are released. If you have not triaged the report, tell them when they can expect a response. If it is not a vulnerability, say so. If it is a bug, find or file a report.
After addressing the report, state what your follow-up will be. Try to estimate the patch development and rollout timelines. Let the reporter know what to expect and give them firm dates on when you will give updates. If you need more time to triage, follow-up with patch delivery timelines afterwards.
Red Flags
Reporters asking for a bug bounty prize in their initial report is a red flag. They should already know if your organization participates in bug bounties. If you have a public policy on bug bounties, point to it. (Bounty web scanners: please stop reporting to distros that their ftp servers are world readable 😫)
2. Security Patch Development
As the coordinator you may not be involved directly with patch development. If you can validate the veracity of the reporters claim (or if you need help), contact the appropriate developers or security point of contact for a team to develop a patch. Usually this involves forwarding the report, adding your analysis, possibly including a CVE-ID, reminding the added party of their embargo responsibilities, and asking for their feedback and development timelines. Patch developers can help shape CRD timelines. Keep the scope of embargo members narrow. Do not share embargoed vulnerability information with people who do not need to know. Do not post sensitive information where unauthorized people have access. When you disclose information, remind others that this information is under embargo and they are responsible for keeping this secret. As the coordinator, you are responsible for planned scope grow.
If needed, remind remediation developers of timelines. Regularly be in contact with reporters and remediators. You do not need to update everyone on details, but communicate periodically.
Coordinators maintain relationships and set boundaries. Like a referee, a coordinator can find themselves between groups. You are responsible to both the reporter and the remediator. Ultimately, all parties are responsible to user security. Motivate, mediate, and push where you can.
Patch Review
When a fix is ready, you may want to share it with the reporter. The reporter has invested time into understanding the affected code. The “fix” may have missed something and reporters often want to protect users and are happy to review security patches. (Incomplete security patches is a recurring problem.) Tell the reporter your timelines, so that they know how long they have to get back to you.
In some cases, investigating an vulnerability can lead to discovering deeper problems. Use your best judgement on what to disclose to the reporter in the given situation.
3. Release Coordination
Depending on the situation (vulnerability, impact, organization, user base, downstreams, etc) coordinating the release with others may or may not be necessary. An exception is to make the reporter aware when the security fix will be announced. Some reporters wish to coordinate releasing their analysis of a vulnerability and we do not want to delay and shortchange the impact of their analysis.
Choosing who to give embargoed information is a matter of trust. For instance, you may want to give downstream software which vendors the affected software a heads up. If that downstream breaks embargo you may not want to trust them in the future.
Note that some groups discourage embargoes. Other groups may hold to CRDs originally agreed to.
Distros List
Vetted distros are subscribed to OpenWall’s distros list. Medium and high impact vulnerabilities that affect the Linux ecosystem should be reported here.
See the mailing list policy. Note the anti-spam dork.
Once contacted, this mailing list prefers that embargo ends after 7-10 days. They enforce a 14 day maximum embargo. Do not contact distros until you are ready. It is best to have a patch to share for review.
After embargo, notify oss-security.
Bare in mind that everything that is sent to this list will be public some day. Generally exploits should not be shared to the list, but you can offer to share exploits privately.
CERT/CC’s VINCE
CERT/CC’s VINCE can help run coordinated vulnerability disclosure.
VINCE is good at connecting vendors together. VINCE is not great at driving patch development, sharing patches ahead of CRD, or timely CVE assignments.
Reporters working with VINCE should (1) make certain they are added to the report, (2) request a CVE early, (3) verify that a CRD is set, and (4) make certain all needed vendors are included. The affected software vendor may be reluctant to disclose information, but a reporter can also share information.