GHSA-w3vc-fx9p-wp4v Jupyter Server Proxy's Websocket Proxying does not require authentication
Summary`jupyter-server-proxy` is used to expose ports local to a Jupyter server listening to web traffic to the Jupyter server's _authenticated users_ by proxying web requests and websockets. Dependent packages ([partial list](https://www.wheelodex.org/projects/jupyter-server-proxy/rdepends/)) also use `jupyter-server-proxy` to expose other popular interactive applications (such as [RStudio](https://github.com/jupyterhub/jupyter-rsession-proxy), [Linux Desktop via VNC](https://github.com/jupyterhub/jupyter-remote-desktop-proxy), [Code Server](https://github.com/betatim/vscode-binder), [Panel](https://github.com/holoviz/jupyter-panel-proxy), etc) along with the Jupyter server. This feature is commonly used in hosted environments (such as a JupyterHub) to expose non-Jupyter interactive frontends or APIs to the user.`jupyter-server-proxy` did not check user authentication appropriately when proxying websockets, allowing unauthenticated access to anyone who had network access to the Jupyter server endpoint.ImpactThis vulnerability can allow unauthenticated remote access to any websocket endpoint set up to be accessible via `jupyter-server-proxy`. In many cases (such as when exposing RStudio via [`jupyter-rsession-proxy`](https://github.com/jupyterhub/jupyter-rsession-proxy) or a remote Linux Desktop / VNC via [`jupyter-remote-desktop-proxy`](https://github.com/jupyterhub/jupyter-remote-desktop-proxy)), this leads to **remote unauthenticated arbitrary code execution**, due to how they use websockets. The websocket endpoints exposed by `jupyter_server` itself is not affected. Projects that do not rely on websockets are also not affected.RemediationUpgrade `jupyter-server-proxy` to a patched version and restart any running Jupyter server.You may not be installing `jupyter-server-proxy` directly, but have it be pulled in as a dependency ([partial list of dependent packages](https://www.wheelodex.org/projects/jupyter-server-proxy/rdepends/)) - so you may be vulnerable even if you aren't directly depending on `jupyter-server-proxy`.For JupyterHub admins of [TLJH] installationsTo secure a tljh deployment's user servers, first check if `jupyter-server-proxy` is installed in the user environment with a vulnerable version. If it is, patch the vulnerability and consider terminating currently running user servers.1. Check for vulnerabilityAs an JupyterHub admin from a terminal in a started user server, you can do:Alternatively as a root user on the server where tljh is installed, you can do:2. Patch detected vulnerabilityAs an JupyterHub admin from a terminal in a started user server, you can do:Alternatively as a root user on the server where tljh is installed, you can do:3. Consider terminating currently running user serversUser servers that started before the patch was applied are still vulnerable. To ensure they aren't vulnerable any more you could forcefully terminate their servers via the JupyterHub web interface at `https://<your domain>/hub/admin`.For JupyterHub admins of [Z2JH] installationsTo secure your z2jh deployment's user servers, first consider if one or more user environments is or may be vulnerable, then ensure new user servers' aren't started with the vulnerability, and finally consider terminating currently running user servers. The steps below guide you to do so.1. Check for vulnerabilitiesConsider all docker images that user servers' environment may be based on. If your deployment expose a fixed set of images, you may be able to update them to non-vulnerable versions.To check if an individual docker image is vulnerable, use a command like:Note that if you reference an image with a mutable tag, such as `quay.io/jupyter/pangeo-notebook:master`, you should ensure a new version is used by configuring the image pull policy so that an older vulnerable version isn't kept being used because it was already available on a Kubernetes node.2. Patch vulnerabilities dynamicallyIf your z2jh deployment still may start vulnerable images for users, you could mount a script that checks and patches the vulnerability before the jupyter server starts.Below is JupyterHub Helm chart configuration that relies on [`singleuser.extraFiles`] and [`singleuser.cmd`] to mount a script we use as an entrypoint to dynamically check and patch the vulnerability before jupyter server is started.Unless you change it, the script will attempt to upgrade `jupyter-server-proxy` to a non-vulnerable version if needed, and error if it needs to and fails. You can adjust this behavior by adjusting the constants `UPGRADE_IF_VULNERABLE` and `ERROR_IF_VULNERABLE` inside the script.3. Consider terminating currently running user serversUser servers that started before the patch was applied are still vulnerable. To ensure they aren't vulnerable any more you could forcefully terminate their servers via the JupyterHub web interface at `https://<your domain>/hub/admin`.Simple ReproductionSetup application to proxyMake a trivial tornado app that has both websocket and regular HTTP endpoints.Setup a clean environment with `jupyter-server-proxy` and start a `jupyter server` instanceWe don't need jupyterlab or anything else here, just `jupyter-server-proxy` would do.Verify HTTP requests require authenticationThis does *not* return the `Hi` response, as expected. Instead, you get the HTML response asking for a token.This is secure as intended.Verify websocket requests doesn't authenticationThe example makes use of [websocat](https://github.com/vi/websocat) to test websockets. You can use any other tool you are familiar with too.At the terminal, type 'Just testing' and press Enter. You'll get `You said: Just testing` without any authentication required.
CVSS v3.1 score: 9