An issue was discovered in Project Jupyter JupyterHub OAuthenticator 0.6.x before 0.6.2 and 0.7.x before 0.7.3. When using JupyterHub with GitLab group whitelisting for access control, group membership was not checked correctly, allowing members not in the whitelisted groups to create accounts on the Hub. (Users were not allowed to access other users' accounts, but could create their own accounts on the Hub linked to their GitLab account. GitLab authentication not using gitlabgroupwhitelist is unaffected. No other Authenticators are affected.)

Summary

An authentication bypass vulnerability in oauthenticator allows an attacker with an unverified email address on an Auth0 tenant to login to JupyterHub. When email is used as the usrnameclaim, this gives users control over their username and the possibility of account takeover.

Impact

This is an Authentication Bypass Vulnerability. Any Auth0 tenant leveraging the Auth0OAuthenticator mapping the email claim to the JupyterHub username is impacted. By default, Auth0 handles email verification as a user flag, not a hard block to authentication streams. If an attacker can register an account with the Auth0 tenant with an unverified email and knows the email of an existing user on the system, they can authenticate as that user.

Patches

- Upgrade oauthenticator to 17.4

Workarounds

- Check emailverified field in an Authenticator.postauthhook function - Do not use email as the username claim - Enforce email verification in auth0

OAuthenticator is an OAuth token library for the JupyerHub login handler. CILogonOAuthenticator is provided by the OAuthenticator package, and lets users log in to a JupyterHub via CILogon. This is primarily used to restrict a JupyterHub only to users of a given institute. The allowedidps configuration trait of CILogonOAuthenticator is documented to be a list of domains that indicate the institutions whose users are authorized to access this JupyterHub. This authorization is validated by ensuring that the email field provided to us by CILogon has a domain that matches one of the domains listed in allowedidps.If allowedidps contains berkeley.edu, you might expect only users with valid current credentials provided by University of California, Berkeley to be able to access the JupyterHub. However, CILogonOAuthenticator does not verify which provider is used by the user to login, only the email address provided. So a user can login with a GitHub account that has email set to <something>@berkeley.edu, and that will be treated exactly the same as someone logging in using the UC Berkeley official Identity Provider. The patch fixing this issue makes a breaking change in how allowedidps is interpreted. It's no longer a list of domains, but configuration representing the EntityID of the IdPs that are allowed, picked from the list maintained by CILogon. Users are advised to upgrade.

Impact

What goes wrong?

The deprecated (in jupyterhub 1.2) configuration Authenticator.whitelist, which should be transparently mapped to Authenticator.allowedusers with a warning, is instead ignored by OAuthenticator classes, resulting in the same behavior as if this configuration has not been set. If this is the only mechanism of authorization restriction (i.e. no group or team restrictions in configuration) then all authenticated users will be allowed. Provider-based restrictions, including deprecated values such as GitHubOAuthenticator.orgwhitelist are not affected.

Who is impacted?

All users of OAuthenticator 0.12.0 and 0.12.1 with JupyterHub 1.2 (JupyterHub Helm chart 0.10.0-0.10.5) who use the admin.whitelist.users configuration in the jupyterhub helm chart or the c.Authenticator.whitelist configuration directly. Users of other deprecated configuration, e.g. c.GitHubOAuthenticator.teamwhitelist are not affected.

If you see a log line like this and expect a specific list of allowed usernames:

[I 2020-11-27 16:51:54.528 JupyterHub app:1717] Not using allowedusers. Any authenticated user will be allowed.

you are likely affected.

Patches

- Replacing deprecated c.Authenticator.whitelist = ... with c.Authenticator.allowedusers = ... avoids the issue. - Update oauthenticator to 0.12.2 - Update jupyterhub helm chart to 0.10.6

If any users have been authorized during this time who should not have been, they must be deleted via the API or admin interface, per the documentation.

Workarounds

Replacing c.Authenticator.whitelist = ... with c.Authenticator.allowedusers = ... avoids the issue.

In the jupyterhub helm chart prior to 0.10.6, this can be done via hub.extraConfig:

yaml auth: allowedUsers: - user1 - user2

hub: extraConfig: allowedUsers: | # set new field not exposed in helm chart < 0.10.6 setconfigifnotnone(c.Authenticator, "allowedusers", "auth.allowedUsers")

For more information

If you have any questions or comments about this advisory:

Open a thread on the Jupyter forum Email us at security@ipython.org