Impact

When JupyterHub is used with FirstUseAuthenticator, the vulnerability allows unauthorized access to any user's account if createusers=True and the username is known or guessed.

Patches

Upgrade to jupyterhub-firstuseauthenticator to 1.0, or apply patch https://github.com/jupyterhub/firstuseauthenticator/pull/38.patch

Workarounds

If you cannot upgrade, there is no complete workaround, but it can be mitigated.

If you cannot upgrade yet, you can disable user creation with c.FirstUseAuthenticator.createusers = False, which will only allow login with fully normalized usernames for already existing users prior to jupyterhub-firstuserauthenticator 1.0. If any users have never logged in with their normalized username (i.e. lowercase), they will still be vulnerable until you can patch or upgrade.

Impact

Due to an unsanitized input, visiting maliciously crafted links could result in arbitrary code execution in the user environment.

Patches

0.10.2

Workarounds

None, other than upgrade to 0.10.2 or downgrade to 0.8.x.

For more information

If you have any questions or comments about this advisory:

Open an issue in nbgitpuller Email our security team at security@ipython.org

Impact user API tokens issued to single-user servers are specified in the environment of systemd units, which are accessible to all users.

In particular, the-littlest-jupyterhub is affected, which uses systemdspawner by default.

Patches Patched in jupyterhub-systemdspawner v0.15

Workarounds No workaround other than upgrading systemdspawner to 0.15

For more information

If you have any questions or comments about this advisory: Open a thread in the Jupyter forum Email us at security@ipython.org

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 namedservers (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 python from traitlets import default from kubespawner import KubeSpawner

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

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

c.JupyterHub.spawnerclass = 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:

Open an issue in kubespawner Email us at security@ipython.org

Credit: Jining Huang