summaryrefslogtreecommitdiffstats
path: root/doc/security
diff options
context:
space:
mode:
Diffstat (limited to '')
-rw-r--r--doc/security/CVE-2021-20288.rst183
-rw-r--r--doc/security/CVE-2021-3509.rst28
-rw-r--r--doc/security/CVE-2021-3524.rst30
-rw-r--r--doc/security/CVE-2021-3531.rst28
-rw-r--r--doc/security/CVE-2022-0670.rst43
-rw-r--r--doc/security/cves.rst114
-rw-r--r--doc/security/index.rst42
-rw-r--r--doc/security/process.rst48
8 files changed, 516 insertions, 0 deletions
diff --git a/doc/security/CVE-2021-20288.rst b/doc/security/CVE-2021-20288.rst
new file mode 100644
index 000000000..fa3b073cb
--- /dev/null
+++ b/doc/security/CVE-2021-20288.rst
@@ -0,0 +1,183 @@
+.. _CVE-2021-20288:
+
+CVE-2021-20288: Unauthorized global_id reuse in cephx
+=====================================================
+
+* `NIST information page <https://nvd.nist.gov/vuln/detail/CVE-2021-20288>`_
+
+Summary
+-------
+
+Ceph was not ensuring that reconnecting/renewing clients were
+presenting an existing ticket when reclaiming their global_id value.
+An attacker that was able to authenticate could claim a global_id in
+use by a different client and potentially disrupt
+other cluster services.
+
+Background
+----------
+
+Each authenticated client or daemon in Ceph is assigned a numeric
+global_id identifier. That value is assumed to be unique across the
+cluster. When clients reconnect to the monitor (e.g., due to a
+network disconnection) or renew their ticket, they are supposed to
+present their old ticket to prove prior possession of their global_id
+so that it can be reclaimed and thus remain constant over the lifetime
+of that client instance.
+
+Ceph was not correctly checking that the old ticket was valid, allowing
+an arbitrary global_id to be reclaimed, even if it was in use by another
+active client in the system.
+
+Attacker Requirements
+---------------------
+
+Any potential attacker must:
+
+* have a valid authentication key for the cluster
+* know or guess the global_id of another client
+* run a modified version of the Ceph client code to reclaim another client's global_id
+* construct appropriate client messages or requests to disrupt service or exploit
+ Ceph daemon assumptions about global_id uniqueness
+
+Impact
+------
+
+Confidentiality Impact
+______________________
+
+None
+
+Integrity Impact
+________________
+
+Partial. An attacker could potentially exploit assumptions around
+global_id uniqueness to disrupt other clients' access or disrupt
+Ceph daemons.
+
+Availability Impact
+___________________
+
+High. An attacker could potentially exploit assumptions around
+global_id uniqueness to disrupt other clients' access or disrupt
+Ceph daemons.
+
+Access Complexity
+_________________
+
+High. The client must make use of modified client code in order to
+exploit specific assumptions in the behavior of other Ceph daemons.
+
+Authentication
+______________
+
+Yes. The attacker must also be authenticated and have access to the
+same services as a client it is wishing to impersonate or disrupt.
+
+Gained Access
+_____________
+
+Partial. An attacker can partially impersonate another client.
+
+Affected versions
+-----------------
+
+All prior versions of Ceph monitors fail to ensure that global_id reclaim
+attempts are authentic.
+
+In addition, all user-space daemons and clients starting from Luminous v12.2.0
+were failing to securely reclaim their global_id following commit a2eb6ae3fb57
+("mon/monclient: hunt for multiple monitor in parallel").
+
+All versions of the Linux kernel client properly authenticate.
+
+Fixed versions
+--------------
+
+* Pacific v16.2.1 (and later)
+* Octopus v15.2.11 (and later)
+* Nautilus v14.2.20 (and later)
+
+
+Fix details
+-----------
+
+#. Patched monitors now properly require that clients securely reclaim
+ their global_id when the ``auth_allow_insecure_global_id_reclaim``
+ is ``false``. Initially, by default, this option is set to
+ ``true`` so that existing clients can continue to function without
+ disruption until all clients have been upgraded. When this option
+ is set to false, then an unpatched client will not be able to reconnect
+ to the cluster after an intermittent network disruption breaking
+ its connect to a monitor, or be able to renew its authentication
+ ticket when it times out (by default, after 72 hours).
+
+ Patched monitors raise the ``AUTH_INSECURE_GLOBAL_ID_RECLAIM_ALLOWED``
+ health alert if ``auth_allow_insecure_global_id_reclaim`` is enabled.
+ This health alert can be muted with::
+
+ ceph health mute AUTH_INSECURE_GLOBAL_ID_RECLAIM_ALLOWED 1w
+
+ Although it is not recommended, the alert can also be disabled with::
+
+ ceph config set mon mon_warn_on_insecure_global_id_reclaim_allowed false
+
+#. Patched monitors can disconnect new clients right after they have
+ authenticated (forcing them to reconnect and reclaim) in order to
+ determine whether they securely reclaim global_ids. This allows
+ the cluster and users to discover quickly whether clients would be
+ affected by requiring secure global_id reclaim: most clients will
+ report an authentication error immediately. This behavior can be
+ disabled by setting ``auth_expose_insecure_global_id_reclaim`` to
+ ``false``::
+
+ ceph config set mon auth_expose_insecure_global_id_reclaim false
+
+#. Patched monitors will raise the ``AUTH_INSECURE_GLOBAL_ID_RECLAIM`` health
+ alert for any clients or daemons that are not securely reclaiming their
+ global_id. These clients should be upgraded before disabling the
+ ``auth_allow_insecure_global_id_reclaim`` option to avoid disrupting
+ client access.
+
+ By default (if ``auth_expose_insecure_global_id_reclaim`` has not
+ been disabled), clients' failure to securely reclaim global_id will
+ immediately be exposed and raise this health alert.
+ However, if ``auth_expose_insecure_global_id_reclaim`` has been
+ disabled, this alert will not be triggered for a client until it is
+ forced to reconnect to a monitor (e.g., due to a network disruption)
+ or the client renews its authentication ticket (by default, after
+ 72 hours).
+
+#. The default time-to-live (TTL) for authentication tickets has been increased
+ from 12 hours to 72 hours. Because we previously were not ensuring that
+ a client's prior ticket was valid when reclaiming their global_id, a client
+ could tolerate a network outage that lasted longer than the ticket TTL and still
+ reclaim its global_id. Once the cluster starts requiring secure global_id reclaim,
+ a client that is disconnected for longer than the TTL may fail to reclaim its global_id,
+ fail to reauthenticate, and be unable to continue communicating with the cluster
+ until it is restarted. The default TTL was increased to minimize the impact of this
+ change on users.
+
+
+Recommendations
+---------------
+
+#. Users should upgrade to a patched version of Ceph at their earliest
+ convenience.
+
+#. Users should upgrade any unpatched clients at their earliest
+ convenience. By default, these clients can be easily identified by
+ checking the ``ceph health detail`` output for the
+ ``AUTH_INSECURE_GLOBAL_ID_RECLAIM`` alert.
+
+#. If all clients cannot be upgraded immediately, the health alerts can be
+ temporarily muted with::
+
+ ceph health mute AUTH_INSECURE_GLOBAL_ID_RECLAIM 1w # 1 week
+ ceph health mute AUTH_INSECURE_GLOBAL_ID_RECLAIM_ALLOWED 1w # 1 week
+
+#. After all clients have been updated and the ``AUTH_INSECURE_GLOBAL_ID_RECLAIM``
+ alert is no longer present, the cluster should be set to prevent insecure
+ global_id reclaim with::
+
+ ceph config set mon auth_allow_insecure_global_id_reclaim false
diff --git a/doc/security/CVE-2021-3509.rst b/doc/security/CVE-2021-3509.rst
new file mode 100644
index 000000000..7e865e9b2
--- /dev/null
+++ b/doc/security/CVE-2021-3509.rst
@@ -0,0 +1,28 @@
+.. _CVE-2021-3509:
+
+CVE-2021-3509: Dashboard XSS via token cookie
+=============================================
+
+* `NIST information page <https://nvd.nist.gov/vuln/detail/CVE-2021-3509>`_
+
+The Ceph Dashboard was vulnerable to an XSS attack that could expose the authentication
+cookie to other sites.
+
+
+Affected versions
+-----------------
+
+* Octopus v15.2.0 and later
+
+Fixed versions
+--------------
+
+* Pacific v16.2.4 (and later)
+* Octopus v15.2.12 (and later)
+* Nautilus v14.2.21 (and later)
+
+
+Recommendations
+---------------
+
+All users of the Ceph dashboard should upgrade.
diff --git a/doc/security/CVE-2021-3524.rst b/doc/security/CVE-2021-3524.rst
new file mode 100644
index 000000000..4d627c071
--- /dev/null
+++ b/doc/security/CVE-2021-3524.rst
@@ -0,0 +1,30 @@
+.. _CVE-2021-3524:
+
+CVE-2021-3524: HTTP header injects via CORS in RGW
+==================================================
+
+* `NIST information page <https://nvd.nist.gov/vuln/detail/CVE-2021-3524>`_
+
+A flaw was found in the radosgw. The vulnerability is related to the
+injection of HTTP headers via a CORS ExposeHeader tag. The \r
+character in the ExposeHeader tag in the CORS configuration file
+generates a header injection in the response when the CORS request is
+made.
+
+Fixed versions
+--------------
+
+* Pacific v16.2.4 (and later)
+* Octopus v15.2.12 (and later)
+* Nautilus v14.2.21 (and later)
+
+Recommendations
+---------------
+
+All users of Ceph object storage (RGW) should upgrade.
+
+Acknowledgements
+----------------
+
+Red Hat would like to thank Sergey Bobrov (Kaspersky) for reporting this issue.
+
diff --git a/doc/security/CVE-2021-3531.rst b/doc/security/CVE-2021-3531.rst
new file mode 100644
index 000000000..907cb4764
--- /dev/null
+++ b/doc/security/CVE-2021-3531.rst
@@ -0,0 +1,28 @@
+.. _CVE-2021-3531:
+
+CVE-2021-3531: Swift API denial of service
+==========================================
+
+* `NIST information page <https://nvd.nist.gov/vuln/detail/CVE-2021-3531>`_
+
+Unauthenticated users of the Swift API can trigger a server-side assertion with a
+malformed URL, leading to a denial of service.
+
+
+Affected versions
+-----------------
+
+* Nautilus v14.2.0 and later
+
+Fixed versions
+--------------
+
+* Pacific v16.2.4 (and later)
+* Octopus v15.2.12 (and later)
+* Nautilus v14.2.21 (and later)
+
+
+Recommendations
+---------------
+
+All users of Ceph object storage (RGW) should upgrade.
diff --git a/doc/security/CVE-2022-0670.rst b/doc/security/CVE-2022-0670.rst
new file mode 100644
index 000000000..f2b90de2e
--- /dev/null
+++ b/doc/security/CVE-2022-0670.rst
@@ -0,0 +1,43 @@
+.. _CVE-2022-0670:
+
+CVE-2022-0670: Native-CephFS Manila Path-restriction bypass
+===========================================================
+
+Summary
+-------
+
+Users who were running OpenStack Manila to export native CephFS and who
+upgraded their Ceph cluster from Nautilus (or earlier) to a later
+major version were vulnerable to an attack by malicious users. The
+vulnerability allowed users to obtain access to arbitrary portions of
+the CephFS filesystem hierarchy instead of being properly restricted
+to their own subvolumes. The vulnerability is due to a bug in the
+"volumes" plugin in Ceph Manager. This plugin is responsible for
+managing Ceph File System subvolumes, which are used by OpenStack
+Manila services as a way to provide shares to Manila users.
+
+Again, this vulnerability impacts only OpenStack Manila clusters that
+provided native CephFS access to their users.
+
+Affected versions
+-----------------
+
+Any version of Ceph running OpenStack Manila that was upgraded from Nautilus
+or earlier.
+
+Fixed versions
+--------------
+
+* Quincy v17.2.2 (and later)
+* Pacific v16.2.10 (and later)
+* Octopus v15.2.17
+
+Recommendations
+---------------
+
+#. Users should upgrade to a patched version of Ceph at their earliest
+ convenience.
+
+#. Administrators who are
+ concerned they may have been impacted should audit the CephX keys in
+ their cluster for proper path restrictions.
diff --git a/doc/security/cves.rst b/doc/security/cves.rst
new file mode 100644
index 000000000..8bbccbf64
--- /dev/null
+++ b/doc/security/cves.rst
@@ -0,0 +1,114 @@
+
+Past vulnerabilities
+====================
+
++------------+-------------------+-------------+---------------------------------------------+
+| Published | CVE | Severity | Summary |
++------------+-------------------+-------------+---------------------------------------------+
+| 2022-07-21 | `CVE-2022-0670`_ | Medium | Native-CephFS Manila Path-restriction bypass|
++------------+-------------------+-------------+---------------------------------------------+
+| 2021-05-13 | `CVE-2021-3531`_ | Medium | Swift API denial of service |
++------------+-------------------+-------------+---------------------------------------------+
+| 2021-05-13 | `CVE-2021-3524`_ | Medium | HTTP header injects via CORS in RGW |
++------------+-------------------+-------------+---------------------------------------------+
+| 2021-05-13 | `CVE-2021-3509`_ | High | Dashboard XSS via token cookie |
++------------+-------------------+-------------+---------------------------------------------+
+| 2021-04-14 | `CVE-2021-20288`_ | High | Unauthorized global_id reuse in cephx |
++------------+-------------------+-------------+---------------------------------------------+
+| 2020-12-18 | `CVE-2020-27781`_ | 7.1 High | CephFS creds read/modified by Manila users |
++------------+-------------------+-------------+---------------------------------------------+
+| 2021-01-08 | `CVE-2020-25678`_ | 4.9 Medium | mgr module passwords in clear text |
++------------+-------------------+-------------+---------------------------------------------+
+| 2020-12-07 | `CVE-2020-25677`_ | 5.5 Medium | ceph-ansible iscsi-gateway.conf perm |
++------------+-------------------+-------------+---------------------------------------------+
+| 2020-11-23 | `CVE-2020-25660`_ | 8.8 High | Cephx replay vulnerability |
++------------+-------------------+-------------+---------------------------------------------+
+| 2020-04-22 | `CVE-2020-12059`_ | 7.5 High | malformed POST could crash RGW |
++------------+-------------------+-------------+---------------------------------------------+
+| 2020-06-26 | `CVE-2020-10753`_ | 6.5 Medium | HTTP header injects via CORS in RGW |
++------------+-------------------+-------------+---------------------------------------------+
+| 2020-06-22 | `CVE-2020-10736`_ | 8.0 High | authorization bypass in mon and mgr |
++------------+-------------------+-------------+---------------------------------------------+
+| 2020-04-23 | `CVE-2020-1760`_ | 6.1 Medium | potential RGW XSS attack |
++------------+-------------------+-------------+---------------------------------------------+
+| 2020-04-13 | `CVE-2020-1759`_ | 6.8 Medium | Cephx nonce reuse in secure mode |
++------------+-------------------+-------------+---------------------------------------------+
+| 2020-02-07 | `CVE-2020-1700`_ | 6.5 Medium | RGW disconnects leak sockets, can DoS |
++------------+-------------------+-------------+---------------------------------------------+
+| 2020-04-21 | `CVE-2020-1699`_ | 7.5 High | Dashboard path traversal flaw |
++------------+-------------------+-------------+---------------------------------------------+
+| 2019-12-23 | `CVE-2019-19337`_ | 6.5 Medium | RGW DoS via malformed headers |
++------------+-------------------+-------------+---------------------------------------------+
+| 2019-11-08 | `CVE-2019-10222`_ | 7.5 High | Invalid HTTP headers could crash RGW |
++------------+-------------------+-------------+---------------------------------------------+
+| 2019-03-27 | `CVE-2019-3821`_ | 7.5 High | RGW file descriptors could be exhausted |
++------------+-------------------+-------------+---------------------------------------------+
+| 2019-01-28 | `CVE-2018-16889`_ | 7.5 High | encryption keys logged in plaintext |
++------------+-------------------+-------------+---------------------------------------------+
+| 2019-01-15 | `CVE-2018-16846`_ | 6.5 Medium | authenticated RGW users can cause DoS |
++------------+-------------------+-------------+---------------------------------------------+
+| 2019-01-15 | `CVE-2018-14662`_ | 5.7 Medium | read-only users could steal dm-crypt keys |
++------------+-------------------+-------------+---------------------------------------------+
+| 2018-07-10 | `CVE-2018-10861`_ | 8.1 High | authenticated user can create/delete pools |
++------------+-------------------+-------------+---------------------------------------------+
+| 2018-03-19 | `CVE-2018-7262`_ | 7.5 High | malformed headers can cause RGW DoS |
++------------+-------------------+-------------+---------------------------------------------+
+| 2018-07-10 | `CVE-2018-1129`_ | 6.5 Medium | network MITM can tamper with messages |
++------------+-------------------+-------------+---------------------------------------------+
+| 2018-07-10 | `CVE-2018-1128`_ | 7.5 High | Cephx replay vulnerability |
++------------+-------------------+-------------+---------------------------------------------+
+| 2018-07-27 | `CVE-2017-7519`_ | 4.4 Medium | libradosstriper unvalidated format string |
++------------+-------------------+-------------+---------------------------------------------+
+| 2018-08-01 | `CVE-2016-9579`_ | 7.6 High | potential RGW XSS attack |
++------------+-------------------+-------------+---------------------------------------------+
+| 2018-07-31 | `CVE-2016-8626`_ | 6.5 Medium | malformed POST can DoS RGW |
++------------+-------------------+-------------+---------------------------------------------+
+| 2016-10-03 | `CVE-2016-7031`_ | 7.5 High | RGW unauthorized bucket listing |
++------------+-------------------+-------------+---------------------------------------------+
+| 2016-07-12 | `CVE-2016-5009`_ | 6.5 Medium | mon command handler DoS |
++------------+-------------------+-------------+---------------------------------------------+
+| 2016-12-03 | `CVE-2015-5245`_ | | RGW header injection |
++------------+-------------------+-------------+---------------------------------------------+
+
+.. toctree::
+ :hidden:
+ :maxdepth: 0
+
+ CVE-2022-0670 <CVE-2022-0670.rst>
+ CVE-2021-3531 <CVE-2021-3531.rst>
+ CVE-2021-3524 <CVE-2021-3524.rst>
+ CVE-2021-3509 <CVE-2021-3509.rst>
+ CVE-2021-20288 <CVE-2021-20288.rst>
+
+.. _CVE-2022-0670: ../CVE-2022-0670
+.. _CVE-2021-3531: ../CVE-2021-3531
+.. _CVE-2021-3524: ../CVE-2021-3524
+.. _CVE-2021-3509: ../CVE-2021-3509
+.. _CVE-2021-20288: ../CVE-2021-20288
+.. _CVE-2020-27781: https://nvd.nist.gov/vuln/detail/CVE-2020-27781
+.. _CVE-2020-25678: https://nvd.nist.gov/vuln/detail/CVE-2020-25678
+.. _CVE-2020-25677: https://nvd.nist.gov/vuln/detail/CVE-2020-25677
+.. _CVE-2020-25660: https://nvd.nist.gov/vuln/detail/CVE-2020-25660
+.. _CVE-2020-12059: https://nvd.nist.gov/vuln/detail/CVE-2020-12059
+.. _CVE-2020-10753: https://nvd.nist.gov/vuln/detail/CVE-2020-10753
+.. _CVE-2020-10736: https://nvd.nist.gov/vuln/detail/CVE-2020-10736
+.. _CVE-2020-1760: https://nvd.nist.gov/vuln/detail/CVE-2020-1760
+.. _CVE-2020-1759: https://nvd.nist.gov/vuln/detail/CVE-2020-1759
+.. _CVE-2020-1700: https://nvd.nist.gov/vuln/detail/CVE-2020-1700
+.. _CVE-2020-1699: https://nvd.nist.gov/vuln/detail/CVE-2020-1699
+.. _CVE-2019-19337: https://nvd.nist.gov/vuln/detail/CVE-2019-19337
+.. _CVE-2019-10222: https://nvd.nist.gov/vuln/detail/CVE-2019-10222
+.. _CVE-2019-3821: https://nvd.nist.gov/vuln/detail/CVE-2019-3821
+.. _CVE-2018-16889: https://nvd.nist.gov/vuln/detail/CVE-2018-16889
+.. _CVE-2018-16846: https://nvd.nist.gov/vuln/detail/CVE-2018-16846
+.. _CVE-2018-14662: https://nvd.nist.gov/vuln/detail/CVE-2018-14662
+.. _CVE-2018-10861: https://nvd.nist.gov/vuln/detail/CVE-2018-10861
+.. _CVE-2018-7262: https://nvd.nist.gov/vuln/detail/CVE-2018-7262
+.. _CVE-2018-1129: https://nvd.nist.gov/vuln/detail/CVE-2018-1129
+.. _CVE-2018-1128: https://nvd.nist.gov/vuln/detail/CVE-2018-1128
+.. _CVE-2017-7519: https://nvd.nist.gov/vuln/detail/CVE-2017-7519
+.. _CVE-2016-9579: https://nvd.nist.gov/vuln/detail/CVE-2016-9579
+.. _CVE-2016-8626: https://nvd.nist.gov/vuln/detail/CVE-2016-8626
+.. _CVE-2016-7031: https://nvd.nist.gov/vuln/detail/CVE-2016-7031
+.. _CVE-2016-5009: https://nvd.nist.gov/vuln/detail/CVE-2016-5009
+.. _CVE-2015-5245: https://nvd.nist.gov/vuln/detail/CVE-2015-5245
diff --git a/doc/security/index.rst b/doc/security/index.rst
new file mode 100644
index 000000000..9d158cb96
--- /dev/null
+++ b/doc/security/index.rst
@@ -0,0 +1,42 @@
+==========
+ Security
+==========
+
+.. toctree::
+ :maxdepth: 1
+
+ Past Vulnerabilities / CVEs <cves>
+ Vulnerability Management Process <process>
+
+Reporting a vulnerability
+=========================
+
+To report a vulnerability, please send email to `security@ceph.io
+<security@ceph.io>`_.
+
+* Please do not file a public ceph tracker issue for a vulnerability.
+* We urge reporters to provide as much information as is practicable
+ (a reproducer, versions affected, fix if available, etc.), as this
+ can speed up the process considerably.
+* Please let us know to whom credit should be given and with what
+ affiliations.
+* If this issue is not yet disclosed publicly and you have any
+ disclosure date in mind, please share the same along with the
+ report.
+
+Although you are not required to, you may encrypt your message using
+the following GPG key:
+
+**6EEF26FFD4093B99: Ceph Security Team (security@ceph.io)**
+
+| **Download:** `MIT PGP Public Key Server <https://pgp.mit.edu/pks/lookup?op=vindex&search=0x6EEF26FFD4093B99>`_
+| **Fingerprint:** A527 D019 21F9 7178 C232 66C1 6EEF 26FF D409 3B99
+
+
+Supported versions
+==================
+
+Security updates are applied only to the current `Active Releases`_.
+
+
+.. _Active Releases: https://docs.ceph.com/en/latest/releases/#active-releases
diff --git a/doc/security/process.rst b/doc/security/process.rst
new file mode 100644
index 000000000..c8a2031ca
--- /dev/null
+++ b/doc/security/process.rst
@@ -0,0 +1,48 @@
+Vulnerability Management Process
+================================
+
+#. The report will be acknowledged within three business days.
+#. The team will investigate the reported issue and will update the email
+ thread with relevant information. The team may ask for additional
+ information regarding the reported issue.
+#. If the team does not confirm the report, no further action will be
+ taken and the issue will be closed.
+#. If the report is confirmed by Ceph team members, a unique CVE identifier
+ will be assigned to the report and then shared with the reporter. The Ceph
+ security team will start working on a fix.
+#. If a reporter has no disclosure date in mind, a Ceph security team
+ member will coordinate a release date (CRD) with the list members
+ and share the mutually agreed disclosure date with the reporter.
+#. The vulnerability disclosure / release date is set excluding Friday and
+ holiday periods.
+#. Embargoes are preferred for Critical and High impact
+ issues. Embargo should not be held for more than 90 days from the
+ date of vulnerability confirmation, except under unusual
+ circumstances. For Low and Moderate issues with limited impact and
+ an easy workaround or where an issue that is already public, a
+ standard patch release process will be followed to fix the
+ vulnerability once CVE is assigned.
+#. Fixes for issues of "Medium" and "Low" severity will be released as part of
+ the next standard release cycle. List members will receive seven days of
+ advance notice prior to the release date of these fixes. The details of the
+ CVE fix will be included in the release notes, and the release notes will be
+ linked in the public announcement.
+#. Commits will be handled in a private repository for review and
+ testing and a new patch version will be released from this private
+ repository.
+#. If a vulnerability is unintentionally already fixed in the public
+ repository, a few days are given to downstream stakeholders/vendors
+ to prepare for updating before the public disclosure.
+#. An announcement will be made disclosing the vulnerability. The
+ fastest place to receive security announcements is via the
+ `ceph-announce@ceph.io <ceph-announce@ceph.io>`_ or
+ `oss-security@lists.openwall.com <oss-security@lists.openwall.com>`_ mailing
+ lists. (These lists are low-traffic).
+
+If the report is considered embargoed, we ask you to not disclose the
+vulnerability before it has been fixed and announced, unless you
+received a response from the Ceph security team that you can do
+so. This holds true until the public disclosure date that was agreed
+upon by the list. Thank you for improving the security of Ceph and its
+ecosystem. Your efforts and responsible disclosure are greatly
+appreciated and will be acknowledged.