FD.io - Vulnerability Management (v3)

This document has been TBD approved by the FD.io TSC replacing the previous version.

Glossary

Term	Definition
Embargo	A time period where vendors have access to details concerning the security vulnerability, with an understanding not to publish these details or the fixes they have prepared. The embargo ends with a coordinated release date ("CRD"). (from source)
Subject Matter Expert	A developer or other specialist who can provide contextual information that helps to determine the validity and impact of a potential security vulnerability.
Peer Reviewed	In the context of a patch, the term "peer reviewed" refers to the patch having been reviewed by the FD.io Security Response Team (SRT) and any other relevant key stakeholders. There is not yet a strict definition of the number of people who need to have reviewed the patch, or how they provide sign off.

Motivation

The FD.io project has gained enough momentum and popularity that the responsible management of security issues in the upstream community is warranted.

Security Response Procedure

Reference procedures

In an attempt to avoid re-inventing the wheel, the FD.io vulnerability management process borrows from the following procedures:

• The Linux Kernel process for reporting security issues

• The OpenDaylight vulnerability management process

• Recommendations for a minimal security response process

Operating Structure

This activity, while not a formal project, is approved and supported by the FD.io Technical Steering Committee (TSC). The FD.io Security Response Team (SRT) functions are as described below.

The FD.io SRT has a chair, appointed by the membership from among the membership via a self-nomination based election, and approved by the FD.io TSC. The FD.io SRT chair is responsible for seeing that work proceeds and serving as a point of contact for the TSC, FD.io community, and the FD.io SRT members. The chair and membership, as well as pointers to this charter and the relevant email lists are documented at VPP Documentation Security Section.

Security supported projects

All FD.io projects are currently in scope for security support.

Security supported versions

All versions of any FD.io project which are actively supported and affected by the security vulnerability, must be patched. This will usually start with the latest version of an affected project. Following that, the FD.io SRT will work with downstream maintainers to ensure that the patch is applied to all maintained and affected versions.

Note: The FD.io SRT needs to provide accurate information about the version the flaw was first introduced so that vendors operating still maintaining older product lines can backport fixes outside of the upstream maintenance window.

Third party components

Third party components (i.e. dependencies) are only in scope for security support if they are statically compiled or otherwise bundled by an FD.io project. Dynamically linked dependencies should patch security vulnerabilities independent of FD.io.

Vulnerability Management Workflow

Workflow for private security vulnerabilities

Reception

A public page must be made available detailing the FD.io vulnerability management process, and providing a single point of contact for contacting the security team. This shall be a private email list that only members of the FD.io SRT and LF-IT admins have access to: <security@lists.fd.io>.

The FD.io SRT should also monitor development mailing lists and bug creation feeds to ensure that there are no issues that have been publicly reported which need to be treated as a security vulnerability. Should such a situation exist the public security issue workflow needs to be followed.

Upon receiving a privately reported security issue the FD.io SRT needs to complete the following tasks.

Extent of disclosure:

• Original Reporter

• FD.io Security Response Team

Next Steps:

1. Send reception confirmation email including a request that the reporter generate a CVSS v4 score and full vector string if one was not included in the original report

2. Validate the CVSS score and vector string. If the FD.io SRT disagrees with the submitter's CVSS score, inform submitter of differences, and come to an agreement on the CVSS score

3. If the issue is determined to NOT be a security vulnerability then inform the reporter that the normal development process is to be followed. The bug should be reported in a GitHub Issue and the project maintainers and committers should be notified via the project's preferred communications medium (e.g. email vpp-dev@lists.fd.io). If a proposed fix is available, it should be submitted via gerrit.fd.io or a GitHub PR based on the project code review process.

4. Otherwise, create a new, private GitHub Security Advisory (GHSA)

5. Add reporter to the private GHSA.

6. Optionally add a subject matter expert to the private GHSA to help triage the flaw

Triage

The GHSA must then be confirmed to be a security vulnerability. This may require the inclusion of a subject matter expert to determine if the problem needs to be treated as a security flaw. If the GHSA is determined not be a security vulnerability then a statement should be added indicating why, the GHSA should then be published and fixed by following the normal development process. Note that once a GHSA has been published, no additional comments can be added to it. Therefore, ensure that all comments have been entered prior to publishing the GHSA.

Should all parties agree that the issue is a security vulnerability then all parties need to work on determining the affected code, assessing the risk to users, and proposing a fix to the flaw. All of this work must be done under embargo. Proposed fixes must not be committed to SCM, and the problem should not be discussed outside of those that have been added to the GHSA.

Extent of disclosure:

• Original Reporter

• FD.io Security Response Team

• Subject Matter Expert (optional)

Next Steps (status: confirmed):

1. Post the confirmed security vulnerability notification in a comment in the private GHSA

2. Determine when the flaw was introduced in the code base and document all release versions of the project that are affected by the flaw to ensure downstream consumers on old, unsupported release versions are made aware they need to upgrade to a supported release or backport patches from a current (i.e. supported) branch

3. Draft an impact description and add it to the private GHSA

4. Confirm that the original reporter wants to be credited for finding the flaw

5. Update the documentation in a private gerrit change in the VPP repository to include the GHSA in the Security Advisories section. If the reported vulnerability is in the VPP repository, then the same gerrit change may be used for both the GHSA patch and the security documentation update

6. Propose a fix / patch for the flaw either in a private gerrit change or using the GHSA PR tooling per the project's normal code review process

7. Get the patch peer reviewed

Next Steps (status: made public after creation of GHSA, i.e. broken embargo):

1. Post a statement in the GHSA explaining why the issue is not classified as a security vulnerability

2. Publish the GHSA

3. If necessary, follow the normal development process to get the anomaly fixed

4. Update the documentation in the VPP repository to include the GHSA and merge it in the master branch

5. Cherry-pick/merge the fix and documentation update to the currently supported release branches

Pre-disclosure

When a patch has been developed and peer reviewed it is then possible to start planning on how and when to announce the security vulnerability. This involves agreeing on a disclosure date.

Extent of Disclosure:

• Original Reporter

• FD.io Security Response Team

• Subject Matter Expert (optional)

Next Steps:

1. Request CVE ID using the GHSA CVE Request tooling

2. Agree on disclosure date with original reporter. This will most likely need to fall on a Tuesday, Wednesday, or a Thursday. Ensure the developer is available at that time to push up the fix.

3. Re-test the patch. Ensure that it still applies to the various branches and that all unit tests pass.

Disclosure date

When the coordinated disclosure date has been reached the assigned member from the FD.io SRT must perform the following tasks.

Extent of Disclosure:

• Everybody. The GHSA will now be public.

Next steps:

1. Re-test the patch and make sure all unit tests pass.

2. Coordinate the submission of the patch. The fix should be fast tracked as it has already been peer reviewed.

3. Create an advisory

4. When the commit has been merged into the code base, an announcement must be sent individually to the following mailing lists: <oss-security@lists.openwall.com>, <discuss@lists.fd.io>, <security-announce@lists.fd.io>

5. Publish the GHSA which will propagate the CVE information to the MITRE CVE database at https://cve.org

Post-disclosure

Post disclosure the standard development process applies. Some optional additional tasks that the FD.io SRT could undertake would be:

• Convert the advisory publication to CVRF format and publish on a separate CVE stream

• Determine the appropriate CWE for this flaw

• Write an automated reproducer of the flaw and add it to the regression tests

• Write a static analysis / lint rule to detect the pattern that lead to the flaw

Handling public security issues

What is considered public?

• Any comment on a public forum, whether it be a mailing list, irc, social media, blog, or news group, that discloses enough of the details of the security vulnerability to enable it to be exploited in the wild.

• Any commit or review comment that indicates that the change may be security related.

Public security vulnerability workflow

There will be occasions where the vulnerability management workflow process is either not followed, or at some stage a party leaks some information about the security vulnerability that makes the issue public. In these cases a different workflow is applicable, as there is no longer any need to maintain an embargo. The private security vulnerability workflow can be followed from the "Disclosure date" step onwards.

Communication

Reception confirmation email

Upon reception of a security report the FD.io security team needs to clearly indicate the expectation of how the issue will be handled.

Thank you for reporting a potential security vulnerability to the FD.io Security Response Team (SRT).

[Optional Section: if CVSS v4.0 score and vector/tag string not submitted in the initial report]
The FD.io TSC Vulnerability Management process requires that the CVSS v4.0 score be calculated
and the score and vector / tag string be submitted by the reporter.

Please use the CVSS v4.0 calculator [0], the documented scoring rubrics [1], and the CVSS
Implementation guide [2] (Threat, Environmental, and Supplemental groups) to evaluate the issue.
Please include both the numeric CVSS v4.0 score and the complete CVSS vector / tag string to this email.

Note: the Supplemental group is optional and may be elided from the calculation as it has no effect on the CVSS score.
[End Optional Section]

All communications and decisions about how this vulnerability will be handled will be
recorded in a GitHub Security Advisory (GHSA) to provide proper tracking, unless the
initial determination is that it is not a vulnerability and is to be treated as a bug
using the normal gerrit change review process.

On behalf of the FD.io SRT, thank you again for your submission to improve {fdio_project}!
{fdio_security_team_member},
FD.io Security Response Team Member

[Optional Section: if CVSS v4.0 score and vector/tag string not submitted in the initial report]
[0] https://nvd.nist.gov/vuln-metrics/cvss/v4-calculator
[1] https://www.first.org/cvss/v4.0/user-guide#Scoring-Rubrics
[2] https://www.first.org/cvss/v4.0/implementation-guide
[End Optional Section]

Confirmed private security issues

Clear instructions need to be provided to all parties involved with the fix as to how the issue needs to be fixed. When the flaw is confirmed, the following statement should be added to the GHSA by a member of the FD.io SRT.

#security-status: confirmed

This issue has been confirmed as a security
vulnerability in { project } and is to be fixed
under the FD.io embargoed security vulnerability
process. Please do not discuss or disclose details
about this flaw prior to the agreed disclosure
date (TBA). All decisions, discussions, and
proposed patches and reviews are to be done via
this tracking issue only.

Confirmed public security issues

When an issue is leaked

#security-status: confirmed-leaked

This issue has been confirmed as a security
vulnerability in { project }. Unfortunately the
details of this flaw have been made public
{ reference_to_leak }. Therefore it cannot be
fixed under the FD.io embargoed security
vulnerability process. As this issue is now public
it is important that the flaw is addressed in a
timely manner. The FD.io SRT will ensure that a
    CVE is assigned for this issue.

When an issue was not reported privately

#security-status: confirmed-public

This issue has been confirmed as a security
vulnerability in { project }. As this issue was
originally a public report it cannot be fixed
under the FD.io embargoed security vulnerability
process. As this issue is public it is important
that the flaw is addressed in a timely manner.
The FD.io SRT will ensure that
    a CVE is assigned for this issue.

Risk Assessment

The FD.io SRT should provide a judgment call for the severity of the issue for the most common use case of the project. The GHSA tooling integrates CVSS v4 calculation into the creation of a GHSA, however, the CVSS score is not the sole metric used to classify a reported issue as a CVE security anomaly.

Red Hat Severity Ratings are to be used as additional criteria or guidance into the severity analysis:

• Critical: This rating is given to flaws that could be easily exploited by a remote unauthenticated attacker and lead to system compromise (arbitrary code execution) without requiring user interaction. These are the types of vulnerabilities that can be exploited by worms. Flaws that require an authenticated remote user, a local user, or an unlikely configuration are not classed as Critical impact.

• Important: This rating is given to flaws that can easily compromise the confidentiality, integrity, or availability of resources. These are the types of vulnerabilities that allow local users to gain privileges, allow unauthenticated remote users to view resources that should otherwise be protected by authentication, allow authenticated remote users to execute arbitrary code, or allow local or remote users to cause a denial of service.

• Moderate: This rating is given to flaws that may be more difficult to exploit but could still lead to some compromise of the confidentiality, integrity, or availability of resources, under certain circumstances. These are the types of vulnerabilities that could have had a Critical impact or Important impact but are less easily exploited based on a technical evaluation of the flaw, or affect unlikely configurations.

• Low: This rating is given to all other issues that have a security impact. These are the types of vulnerabilities that are believed to require unlikely circumstances to be able to be exploited, or where a successful exploit would give minimal consequences.

Description: The description must endeavor to accurately depict the nature of the flaw. Information that should be included must indicate the attack vector that is exposed by the flaw and the initial access level required by the attacker. Where applicable, provide advice on how an operator may audit for abuse of the flaw within their environment.

CVE Request

To ensure proper traceability a CVE identifier needs to be requested from a CNA. GitHub is a CNA which is directly integrated into the GHSA tooling in both the request phase and disclosure / publication phase.