doc/guides/contributing/vulnerability.rst

   1 ..  SPDX-License-Identifier: BSD-3-Clause
   2     Copyright 2019 The DPDK contributors
   3
   4 DPDK Vulnerability Management Process
   5 =====================================
   6
   7 Scope
   8 -----
   9
  10 Only the main repositories (dpdk and dpdk-stable) of the core project
  11 are in the scope of this security process.
  12 If a stable branch is declared unmaintained (end of life),
  13 no fix will be applied.
  14
  15 All vulnerabilities are bugs, but not every bug is a vulnerability.
  16 Vulnerabilities compromise one or more of:
  17
  18 * Confidentiality (personal or corporate confidential data).
  19 * Integrity (trustworthiness and correctness).
  20 * Availability (uptime and service).
  21
  22 If in doubt, please consider the vulnerability as security sensitive.
  23 At worst, the response will be to report the bug through the usual channels.
  24
  25
  26 Finding
  27 -------
  28
  29 There is no pro-active security engineering effort at the moment.
  30
  31 Please report any security issue you find in DPDK as described below.
  32
  33
  34 Report
  35 ------
  36
  37 Do not use Bugzilla (unsecured).
  38 Instead, send GPG-encrypted emails
  39 to `security@dpdk.org <https://core.dpdk.org/security#contact>`_.
  40 Anyone can post to this list.
  41 In order to reduce the disclosure of a vulnerability in the early stages,
  42 membership of this list is intentionally limited to a `small number of people
  43 <https://mails.dpdk.org/roster/security>`_.
  44
  45 It is additionally encouraged to GPG-sign one-on-one conversations
  46 as part of the security process.
  47
  48 As it is with any bug, the more information provided,
  49 the easier it will be to diagnose and fix.
  50 If you already have a fix, please include it with your report,
  51 as that can speed up the process considerably.
  52
  53 In the report, please note how you would like to be credited
  54 for discovering the issue
  55 and the details of any embargo you would like to impose.
  56
  57 If the vulnerability is not public yet,
  58 no patch or information should be disclosed publicly.
  59 If a fix is already published,
  60 the reporting process must be followed anyway, as described below.
  61
  62
  63 Confirmation
  64 ------------
  65
  66 Upon reception of the report, a security team member should reply
  67 to the reporter acknowledging that the report has been received.
  68
  69 The DPDK security team reviews the security vulnerability reported.
  70 Area experts not members of the security team may be involved in the process.
  71 In case the reported issue is not qualified as a security vulnerability,
  72 the security team will request the submitter to report it
  73 using the usual channel (Bugzilla).
  74 If qualified, the security team will assess which DPDK version are affected.
  75 A bugzilla ID (allocated in a `reserved pool
  76 <https://bugs.dpdk.org/buglist.cgi?f1=bug_group&o1=equals&v1=security>`_)
  77 is assigned to the vulnerability, and kept empty until public disclosure.
  78
  79 The security team calculates the severity score with
  80 `CVSS calculator <https://www.first.org/cvss/calculator/3.0>`_
  81 based on inputs from the reporter and its own assessment of the vulnerability,
  82 and agrees on the score with the reporter.
  83
  84 An embargo may be put in place depending on the severity of the vulnerability.
  85 If an embargo is decided, its duration should be suggested by the security team
  86 and negotiated with the reporter.
  87 Embargo duration between vulnerability confirmation and public disclosure
  88 should be between **one and ten weeks**.
  89 If an embargo is not required, the vulnerability may be fixed
  90 using the standard patch process, once a CVE number has been assigned.
  91
  92 The confirmation mail should be sent within **3 business days**.
  93
  94 Following information must be included in the mail:
  95
  96 * Confirmation
  97 * CVSS severity and score
  98 * Embargo duration
  99 * Reporter credit
 100 * Bug ID (empty and restricted for future reference)
 101
 102 CVE Request
 103 -----------
 104
 105 The security team develops a security advisory document.
 106 The security team may, at its discretion,
 107 include the reporter (via "CC") in developing the security advisory document,
 108 but in any case should accept feedback
 109 from the reporter before finalizing the document.
 110 When the document is final, the security team needs to
 111 request a CVE identifier from a CNA.
 112
 113 The CVE request should be sent
 114 to `secalert@redhat.com <mailto:secalert@redhat.com>`_
 115 using GPG encrypted email
 116 (see `contact details <https://access.redhat.com/security/team/contact>`_).
 117
 118
 119 CVE Request Template with Embargo
 120 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 121
 122 ::
 123
 124   A vulnerability was discovered in the DPDK project.
 125   In order to ensure full traceability, we need a CVE number assigned
 126   that we can attach to private and public notifications.
 127   Please treat the following information as confidential during the embargo
 128   until further public disclosure.
 129
 130   [PRODUCT]:
 131   [VERSION]:
 132   [PROBLEMTYPE]:
 133   [SEVERITY]:
 134   [REFERENCES]: { bug_url }
 135   [DESCRIPTION]:
 136
 137   Thanks
 138   { DPDK_security_team_member }, on behalf of the DPDK security team
 139
 140
 141 CVE Request Template without Embargo
 142 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 143
 144 ::
 145
 146   A vulnerability was discovered in the DPDK project.
 147   In order to ensure full traceability, we need a CVE number assigned
 148   that we can attach to private and public notifications.
 149
 150   [PRODUCT]:
 151   [VERSION]:
 152   [PROBLEMTYPE]:
 153   [SEVERITY]:
 154   [REFERENCES]: { bug_url }
 155   [DESCRIPTION]:
 156
 157   Thanks
 158   { DPDK_security_team_member }, on behalf of the DPDK security team
 159
 160
 161 Fix Development and Review
 162 --------------------------
 163
 164 If the fix is already published, this step is skipped,
 165 and the pre-release disclosure is replaced with the private disclosure,
 166 as described below. It must not be considered as the standard process.
 167
 168 This step may be started in parallel with CVE creation.
 169 The patches fixing the vulnerability are developed and reviewed
 170 by the security team and
 171 by elected area experts that agree to maintain confidentiality.
 172
 173 The CVE id and the bug id must be referenced in the patch.
 174
 175 Backports to the identified affected versions are done once the fix is ready.
 176
 177
 178 Pre-Release Disclosure
 179 ----------------------
 180
 181 When the fix is ready, the security advisory and patches are sent
 182 to downstream stakeholders
 183 (`security-prerelease@dpdk.org <mailto:security-prerelease@dpdk.org>`_),
 184 specifying the date and time of the end of the embargo.
 185 The public disclosure should happen in **less than one week**.
 186
 187 Downstream stakeholders are expected not to deploy or disclose patches
 188 until the embargo is passed, otherwise they will be removed from the list.
 189
 190 Downstream stakeholders (in `security-prerelease list
 191 <https://mails.dpdk.org/roster/security-prerelease>`_), are:
 192
 193 * Operating system vendors known to package DPDK
 194 * Major DPDK users, considered trustworthy by the technical board, who
 195   have made the request to `techboard@dpdk.org <mailto:techboard@dpdk.org>`_
 196
 197 The `OSS security private mailing list mailto:distros@vs.openwall.org>` will
 198 also be contacted one week before the end of the embargo, as indicated by `the
 199 OSS-security process <https://oss-security.openwall.org/wiki/mailing-lists/distros>`
 200 and using the PGP key listed on the same page, describing the details of the
 201 vulnerability and sharing the patch[es]. Distributions and major vendors follow
 202 this private mailing list, and it functions as a single point of contact for
 203 embargoed advance notices for open source projects.
 204
 205 The security advisory will be based on below template,
 206 and will be sent signed with a security team's member GPG key.
 207
 208
 209 Pre-Release Mail Template
 210 ~~~~~~~~~~~~~~~~~~~~~~~~~
 211
 212 ::
 213
 214   This is an advance warning of a vulnerability discovered in DPDK,
 215   to give you, as downstream stakeholders, a chance to coordinate
 216   the release of fixes and reduce the vulnerability window.
 217   Please treat the following information as confidential until
 218   the proposed public disclosure date.
 219
 220   { impact_description }
 221
 222   Proposed patches are attached.
 223   Unless a flaw is discovered in them, these patches will be merged
 224   to { branches } on the public disclosure date.
 225
 226   CVE: { cve_id }
 227   Severity: { severity }
 228   CVSS scores: { cvss_scores }
 229
 230   Proposed public disclosure date/time: { disclosure_date } at 15:00 UTC.
 231   Please do not make the issue public (or release public patches)
 232   before this coordinated embargo date.
 233
 234 If the issue is leaked during the embargo, the same procedure is followed
 235 with only a few days delay between the pre-release and the public disclosure.
 236
 237
 238 Private Disclosure
 239 ------------------
 240
 241 If a vulnerability is unintentionally already fixed in the public repository,
 242 a security advisory is sent to downstream stakeholders
 243 (`security-prerelease@dpdk.org <mailto:security-prerelease@dpdk.org>`_),
 244 giving few days to prepare for updating before the public disclosure.
 245
 246
 247 Private Disclosure Mail Template
 248 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 249
 250 ::
 251
 252   This is a warning of a vulnerability discovered in DPDK,
 253   to give you, as downstream stakeholders, a chance to coordinate
 254   the deployment of fixes before a CVE is public.
 255
 256   Please treat the following information as confidential until
 257   the proposed public disclosure date.
 258
 259   { impact_description }
 260
 261   Commits: { commit_ids with branch number }
 262
 263   CVE: { cve_id }
 264   Severity: { severity }
 265   CVSS scores: { cvss_scores }
 266
 267   Proposed public disclosure date/time: { disclosure_date }.
 268   Please do not make the vulnerability information public
 269   before this coordinated embargo date.
 270
 271
 272 Public Disclosure
 273 -----------------
 274
 275 On embargo expiration, following tasks will be done simultaneously:
 276
 277 * The assigned bug is filled by a member of the security team,
 278   with all relevant information, and it is made public.
 279 * The patches are pushed to the appropriate branches.
 280 * For long and short term stable branches fixed,
 281   new versions should be released.
 282
 283 Releases on Monday to Wednesday are preferred, so that system administrators
 284 do not have to deal with security updates over the weekend.
 285
 286 The security advisory is posted
 287 to `announce@dpdk.org <mailto:announce@dpdk.org>`_ and to `the public OSS-security
 288 mailing list <mailto:oss-security@lists.openwall.com>` as soon as the patches
 289 are pushed to the appropriate branches.
 290
 291 Patches are then sent to `dev@dpdk.org <mailto:dev@dpdk.org>`_
 292 and `stable@dpdk.org <mailto:stable@dpdk.org>`_ accordingly.
 293
 294
 295 Release Mail Template
 296 ~~~~~~~~~~~~~~~~~~~~~
 297
 298 ::
 299
 300   A vulnerability was fixed in DPDK.
 301   Some downstream stakeholders were warned in advance
 302   in order to coordinate the release of fixes
 303   and reduce the vulnerability window.
 304
 305   { impact_description }
 306
 307   Commits: { commit_ids with branch number }
 308
 309   CVE: { cve_id }
 310   Bugzilla: { bug_url }
 311   Severity: { severity }
 312   CVSS scores: { cvss_scores }
 313
 314
 315 References
 316 ----------
 317
 318 * `A minimal security response process
 319   <https://access.redhat.com/blogs/766093/posts/1975833>`_
 320 * `fd.io Vulnerability Management
 321   <https://wiki.fd.io/view/TSC:Vulnerability_Management>`_
 322 * `Open Daylight Vulnerability Management
 323   <https://wiki.opendaylight.org/view/Security:Vulnerability_Management>`_
 324 * `CVE Assignment Information Format
 325   <https://cve.mitre.org/cve/list_rules_and_guidance/cve_assignment_information_format.html>`_