Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Server Proxy does not forbid users to access web apps of other users running on same host #358

Closed
mahendrapaipuri opened this issue Nov 19, 2022 · 3 comments · Fixed by #359
Labels

Comments

@mahendrapaipuri
Copy link

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

FROM debian:stable-slim

ARG DEBIAN_FRONTEND=noninteractive

# Install prerequisites
RUN apt-get update -y && apt-get install apt-utils -y && \
                         apt-get install vim \
                                         git \
                                         curl \
                                         python3.9 \
                                         python3-pip -y
                                         
# Install node
RUN curl -fsSL https://deb.nodesource.com/setup_18.x | bash - && \
    apt-get install -y nodejs

# Add users
RUN useradd --shell /bin/bash --home-dir /home/user1 -p $(openssl passwd -1 user1) --create-home user1 && \
    useradd --shell /bin/bash --home-dir /home/user2 -p $(openssl passwd -1 user2) --create-home user2

# Install Jupyterlab and jupyter server proxy
RUN pip install --no-cache-dir jupyterlab==3.5.0 jupyter_server_proxy==3.2.2 tensorboard==2.11.0

# Expose port
EXPOSE 8888

# Entrypoint
CMD ["bash"]

Now start a jupyterlab instance as user user1

docker run -p 9999:8888 --rm -it --name jsp_test jsp
root@b20fcea9b498:/# su - user1
user1@b20fcea9b498:~$ jupyter-lab --ip=0.0.0.0

Now open another shell as start a tensorboard instance as user2

docker exec -it jsp_test bash
root@b20fcea9b498:/# su - user2
user2@b20fcea9b498:~$ tensorboard --logdir /home/user2 --port 7001

Now if we go to http://localhost:9999/proxy/7001/, we can access the tensorboard instance of user2

Screenshot 2022-11-19 at 19 49 43

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.

@welcome
Copy link

welcome bot commented Nov 19, 2022

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.
welcome
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! 👋

Welcome to the Jupyter community! 🎉

@manics
Copy link
Member

manics commented Nov 19, 2022

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.

If you have more questioned please create a post on https://discourse.jupyter.org/

@takluyver
Copy link
Member

#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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants