Описание
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) also use jupyter-server-proxy to expose other popular interactive applications (such as RStudio, Linux Desktop via VNC, Code Server, Panel, 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.
Impact
This 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 or a remote Linux Desktop / VNC via 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.
Remediation
Upgrade 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) - so you may be vulnerable even if you aren't directly depending on jupyter-server-proxy.
For JupyterHub admins of TLJH installations
Expand to read more
To 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 vulnerability
As 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 vulnerability
As 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 servers
User 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 installations
Expand to read more
To 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 vulnerabilities
Consider 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 dynamically
If 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 servers
User 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 Reproduction
Expand to read more
Setup application to proxy
Make 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 instance
We don't need jupyterlab or anything else here, just jupyter-server-proxy would do.
Verify HTTP requests require authentication
This 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 authentication
The example makes use of 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.
Ссылки
- https://github.com/jupyterhub/jupyter-server-proxy/security/advisories/GHSA-w3vc-fx9p-wp4v
- https://nvd.nist.gov/vuln/detail/CVE-2024-28179
- https://github.com/jupyterhub/jupyter-server-proxy/commit/764e499f61a87641916a7a427d4c4b1ac3f321a9
- https://github.com/jupyterhub/jupyter-server-proxy/commit/bead903b7c0354b6efd8b4cde94b89afab653e03
- https://github.com/jupyterhub/jupyter-server-proxy/blob/9b624c4d9507176334b46a85d94a4aa3bcd29bed/jupyter_server_proxy/handlers.py#L433
- https://github.com/pypa/advisory-database/tree/main/vulns/jupyter-server-proxy/PYSEC-2024-234.yaml
Пакеты
jupyter-server-proxy
>= 4.0.0, < 4.1.1
4.1.1
jupyter-server-proxy
< 3.2.3
3.2.3
Связанные уязвимости
Jupyter Server Proxy allows users to run arbitrary external processes alongside their Jupyter notebook servers and provides authenticated web access. Prior to versions 3.2.3 and 4.1.1, 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. This vulnerability can allow unauthenticated remote access to any websocket endpoint set up to be accessible via Jupyter Server Proxy. In many cases, this leads to remote unauthenticated arbitrary code execution, due to how affected instances use websockets. The websocket endpoints exposed by `jupyter_server` itself is not affected. Projects that do not rely on websockets are also not affected. Versions 3.2.3 and 4.1.1 contain a fix for this issue.
Уязвимость программного средства запуска и проксирования веб-приложений Jupyter Server Proxy, связанная с отсутствием аутентификации для критичной функции, позволяющая нарушителю выполнить произвольный код