diff options
Diffstat (limited to '')
| -rw-r--r-- | doc/security/CVE-2021-20288.rst | 183 | ||||
| -rw-r--r-- | doc/security/CVE-2021-3509.rst | 28 | ||||
| -rw-r--r-- | doc/security/CVE-2021-3524.rst | 30 | ||||
| -rw-r--r-- | doc/security/CVE-2021-3531.rst | 28 | ||||
| -rw-r--r-- | doc/security/CVE-2022-0670.rst | 43 | ||||
| -rw-r--r-- | doc/security/cves.rst | 114 | ||||
| -rw-r--r-- | doc/security/index.rst | 42 | ||||
| -rw-r--r-- | doc/security/process.rst | 48 |
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. |