You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It seems like Jupyter server proxy does not stop one user to proxy to web application of another user running on the same host. If the web app does not have any authentication, any user can proxy to app of any other using just by knowing on which port the web app is running.
Reproducer:
We can reproduce it in container setup. Build a container with following Dockerfile
Now if we go to http://localhost:9999/proxy/7001/, we can access the tensorboard instance of user2
Use case:
This can be a potential security issue on multi tenant systems like HPC platforms. This is a very common scenario in HPC environment that multiple users run their jupyterlab instances on the same host.
Potential Fix:
One straight-forward fix is to check if current user owns the process before proxying to the application. I have verified that on Linux and it works well. I am not quite sure if it works on Windows and Mac though.
The text was updated successfully, but these errors were encountered:
Thank you for opening your first issue in this project! Engagement like this is essential for open source projects! 🤗
If you haven't done so already, check out Jupyter's Code of Conduct. Also, please try to follow the issue template as it helps other other community members to contribute more effectively.
You can meet the other Jovyans by joining our Discourse forum. There is also an intro thread there where you can stop by and say Hi! 👋
Hi! This is intentional. jupyter-server-proxy has the same permissions as the user running JupyterLab. For example, even if there are no extensions installed a user can write a notebook that makes a network request to any internal server. Since jupyter-server-proxy is accessed via JupyterLab the user still has to be authenticated with the JupyterLab token. If your HPC user has access to the terminal they could easily run netcat or any other network proxying tool (or they could write their own in whatever programming languages are installed on your system), without Jupyter.
#337 would fix this in certain cases, by proxying a Unix socket, where access is controlled by filesystem permissions, rather than a TCP socket, which is accessible to all users. This would only work for processes launched by JSP, which know how to listen on a Unix socket, and only on Unix-y systems, but hopefully it's still a step fowards.
Hello,
It seems like Jupyter server proxy does not stop one user to proxy to web application of another user running on the same host. If the web app does not have any authentication, any user can proxy to app of any other using just by knowing on which port the web app is running.
Reproducer:
We can reproduce it in container setup. Build a container with following
Dockerfile
Now start a
jupyterlab
instance as useruser1
Now open another shell as start a
tensorboard
instance asuser2
Now if we go to
http://localhost:9999/proxy/7001/
, we can access thetensorboard
instance ofuser2
Use case:
This can be a potential security issue on multi tenant systems like HPC platforms. This is a very common scenario in HPC environment that multiple users run their
jupyterlab
instances on the same host.Potential Fix:
One straight-forward fix is to check if current user owns the process before proxying to the application. I have verified that on Linux and it works well. I am not quite sure if it works on Windows and Mac though.
The text was updated successfully, but these errors were encountered: