GHSA-V7M9-9497-P9GR

Vulnerability from github – Published: 2020-07-22 23:07 – Updated: 2024-09-24 20:43
VLAI?
Summary
Possible pod name collisions in jupyterhub-kubespawner
Details

Impact

What kind of vulnerability is it? Who is impacted?

JupyterHub deployments using:

  • KubeSpawner <= 0.11.1 (e.g. zero-to-jupyterhub 0.9.0) and
  • enabled named_servers (not default), and
  • an Authenticator that allows:
  • usernames with hyphens or other characters that require escape (e.g. user-hyphen or user@email), and
  • usernames which may match other usernames up to but not including the escaped character (e.g. user in the above cases)

In this circumstance, certain usernames will be able to craft particular server names which will grant them access to the default server of other users who have matching usernames.

Patches

Has the problem been patched? What versions should users upgrade to?

Patch will be released in kubespawner 0.12 and zero-to-jupyterhub 0.9.1

Workarounds

Is there a way for users to fix or remediate the vulnerability without upgrading?

KubeSpawner

Specify configuration:

for KubeSpawner

from traitlets import default
from kubespawner import KubeSpawner

class PatchedKubeSpawner(KubeSpawner):
    @default("pod_name_template")
    def _default_pod_name_template(self):
        if self.name:
            return "jupyter-{username}-{servername}"
        else:
            return "jupyter-{username}"

    @default("pvc_name_template")
    def _default_pvc_name_template(self):
        if self.name:
            return "claim-{username}-{servername}"
        else:
            return "claim-{username}"

c.JupyterHub.spawner_class = PatchedKubeSpawner

Note for KubeSpawner: this configuration will behave differently before and after the upgrade, so will need to be removed when upgrading. Only apply this configuration while still using KubeSpawner ≤ 0.11.1 and remove it after upgrade to ensure consistent pod and pvc naming.

Changing the name template means pvcs for named servers will have different names. This will result in orphaned PVCs for named servers across Hub upgrade! This may appear as data loss for users, depending on configuration, but the orphaned PVCs will still be around and data can be migrated manually (or new PVCs created manually to reference existing PVs) before deleting the old PVCs and/or PVs.

References

Are there any links users can visit to find out more?

For more information

If you have any questions or comments about this advisory:

Credit: Jining Huang

Severity ?
6.8 (Medium)
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N
7.6 (High)
CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.11.1"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "jupyterhub-kubespawner"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.12.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2020-15110"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2020-07-17T20:49:37Z",
    "nvd_published_at": "2020-07-17T21:15:00Z",
    "severity": "HIGH"
  },
  "details": "### Impact\n_What kind of vulnerability is it? Who is impacted?_\n\nJupyterHub deployments using:\n\n- KubeSpawner \u003c= 0.11.1 (e.g. zero-to-jupyterhub 0.9.0) and\n- enabled named_servers (not default), and\n- an Authenticator that allows:\n  - usernames with hyphens or other characters that require escape (e.g. `user-hyphen` or `user@email`), and\n  - usernames which may match other usernames up to but not including the escaped character (e.g. `user` in the above cases)\n\nIn this circumstance, certain usernames will be able to craft particular server names which will grant them access to the default server of other users who have matching usernames.\n\n### Patches\n_Has the problem been patched? What versions should users upgrade to?_\n\nPatch will be released in kubespawner 0.12 and zero-to-jupyterhub 0.9.1\n\n### Workarounds\n_Is there a way for users to fix or remediate the vulnerability without upgrading?_\n\n#### KubeSpawner\n\nSpecify configuration:\n\nfor KubeSpawner\n```python\nfrom traitlets import default\nfrom kubespawner import KubeSpawner\n\nclass PatchedKubeSpawner(KubeSpawner):\n    @default(\"pod_name_template\")\n    def _default_pod_name_template(self):\n        if self.name:\n            return \"jupyter-{username}-{servername}\"\n        else:\n            return \"jupyter-{username}\"\n\n    @default(\"pvc_name_template\")\n    def _default_pvc_name_template(self):\n        if self.name:\n            return \"claim-{username}-{servername}\"\n        else:\n            return \"claim-{username}\"\n\nc.JupyterHub.spawner_class = PatchedKubeSpawner\n```\n\n**Note for KubeSpawner:** this configuration will behave differently before and after the upgrade, so will need to be removed when upgrading. Only apply this configuration while still using KubeSpawner \u2264 0.11.1 and remove it after upgrade to ensure consistent pod and pvc naming.\n\nChanging the name template means pvcs for named servers will have different names. This will result in orphaned PVCs for named servers across Hub upgrade! This may appear as data loss for users, depending on configuration, but the orphaned PVCs will still be around and data can be migrated manually (or new PVCs created manually to reference existing PVs) before deleting the old PVCs and/or PVs.\n\n### References\n_Are there any links users can visit to find out more?_\n\n### For more information\nIf you have any questions or comments about this advisory:\n\n* Open an issue in [kubespawner](https://github.com/jupyterhub/kubespawner)\n* Email us at [security@ipython.org](mailto:security@ipython.org)\n\nCredit: Jining Huang",
  "id": "GHSA-v7m9-9497-p9gr",
  "modified": "2024-09-24T20:43:31Z",
  "published": "2020-07-22T23:07:16Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/jupyterhub/kubespawner/security/advisories/GHSA-v7m9-9497-p9gr"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-15110"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jupyterhub/kubespawner/commit/3dfe870a7f5e98e2e398b01996ca6b8eff4bb1d0"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/jupyterhub/kubespawner"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/jupyterhub-kubespawner/PYSEC-2020-51.yaml"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Possible pod name collisions in jupyterhub-kubespawner"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.



Detection rules are retrieved from Rulezet.