jupyterlab is an extensible environment for interactive and reproducible computing, based on the Jupyter Notebook Architecture. Prior to 4.5.7, JupyterLab's HTML sanitizer allowlists data-commandlinker-command and data-commandlinker-args on button elements, while CommandLinker listens for all click events on document.body and executes the named command without checking whether the element came from trusted JupyterLab UI. A notebook with a pre-saved HTML cell output containing a deceptive button can trigger arbitrary JupyterLab commands - including arbitrary code execution - on a single user click, without any code being submitted for execution by the user. This vulnerability is fixed in 4.5.7.

Impact

The vulnerability depends on user interaction by opening a malicious notebook with Markdown cells, or Markdown file using JupyterLab preview feature.

A malicious user can access any data that the attacked user has access to as well as perform arbitrary requests acting as the attacked user.

Patches

JupyterLab v3.6.8, v4.2.5 and Jupyter Notebook v7.2.2 were patched.

Workarounds

There is no workaround for the underlying DOM Clobbering susceptibility. However, select plugins can be disabled on deployments which cannot update in a timely fashion to minimise the risk. These are: - @jupyterlab/mathjax-extension:plugin - users will loose ability to preview mathematical equations - @jupyterlab/markdownviewer-extension:plugin - users will loose ability to open Markdown previews - @jupyterlab/mathjax2-extension:plugin (if installed with optional jupyterlab-mathjax2 package) - an older version of the mathjax plugin for JupyterLab 4.x

To disable these extensions run:

bash jupyter labextension disable @jupyterlab/markdownviewer-extension:plugin jupyter labextension disable @jupyterlab/mathjax-extension:plugin jupyter labextension disable @jupyterlab/mathjax2-extension:plugin

To confirm that the plugins were disabled run:

bash jupyter labextension list

References

None

Notes

This change has a potential to break rendering of some markdown. There is a setting in Sanitizer which allows to revert to the previous sanitizer settings (allowNamedProperties).

Impact Users of JupyterLab who click on a malicious link may get their Authorization and XSRFToken tokens exposed to a third party when running an older jupyter-server version.

Patches JupyterLab 4.1.0b2, 4.0.11, and 3.6.7 were patched.

Workarounds No workaround has been identified, however users should ensure to upgrade jupyter-server to version 2.7.2 or newer which includes a redirect vulnerability fix.

References

Vulnerability reported by user @davwwwx via the bug bounty program sponsored by the European Commission and hosted on the Intigriti platform.

Impact

The vulnerability depends on user interaction by opening a malicious notebook with Markdown cells, or Markdown file using JupyterLab preview feature.

A malicious user can access any data that the attacked user has access to as well as perform arbitrary requests acting as the attacked user.

Patches

JupyterLab v4.0.11 was patched.

Workarounds

Users can either disable the table of contents extension by running:

bash jupyter labextension disable @jupyterlab/toc-extension:registry

References

Vulnerability reported via the bug bounty program sponsored by the European Commission and hosted on the Intigriti platform.

Jupyter Notebook is a web-based notebook environment for interactive computing. Prior to version 6.4.12, authenticated requests to the notebook server with ContentsManager.allowhidden = False only prevented listing the contents of hidden directories, not accessing individual hidden files or files in hidden directories (i.e. hidden files were 'hidden' but not 'inaccessible'). This could lead to notebook configurations allowing authenticated access to files that may reasonably be expected to be disallowed. Because fully authenticated requests are required, this is of relatively low impact. But if a server's root directory contains sensitive files whose only protection from the server is being hidden (e.g. ~/.ssh while serving $HOME), then any authenticated requests could access files if their names are guessable. Such contexts also necessarily have full access to the server and therefore execution permissions, which also generally grants access to all the same files. So this does not generally result in any privilege escalation or increase in information access, only an additional, unintended means by which the files could be accessed. Version 6.4.12 contains a patch for this issue. There are currently no known workarounds.

Jupyter Notebook could allow a remote attacker to obtain sensitive information, caused by the storage of auth cookie and other header values in the log files when a 5xx error is triggered. By gaining access to the log files, an attacker could exploit this vulnerability to obtain sensitive information, and use this information to launch further attacks against the affected system.

Impact

Untrusted notebook can execute code on load. This is a remote code execution, but requires user action to open a notebook.

Patches

5.7.11, 6.4.1

References

OWASP Page on Injection Prevention

For more information

If you have any questions or comments about this advisory, or vulnerabilities to report, please email our security list security@ipython.org.

Credit: Guillaume Jeanne from Google

Example:

A notebook with the following content in a cell and it would display an alert when opened for the first time in Notebook (in an untrusted state):

{ "celltype": "code", "executioncount": 0, "metadata": {}, "outputs": [ { "data": { "text/html": [ "<select><iframe></select><img src=x: onerror=alert('xss')>\n"], "text/plain": [] }, "metadata": {}, "outputtype": "displaydata" } ], "source": [ "" ] }

Impact What kind of vulnerability is it? Who is impacted?

Open redirect vulnerability - a maliciously crafted link to a notebook server could redirect the browser to a different website.

All notebook servers are technically affected, however, these maliciously crafted links can only be reasonably made for known notebook server hosts. A link to your notebook server may appear safe, but ultimately redirect to a spoofed server on the public internet.

Patches

Has the problem been patched? What versions should users upgrade to?

Patched in notebook 6.1.5

References

OWASP page on open redirects

For more information

If you have any questions or comments about this advisory, or vulnerabilities to report, please email our security list security@ipython.org.

Credit: zhuonan li of Alibaba Application Security Team

Jupyter Notebook before 5.5.0 does not use a CSP header to treat served files as belonging to a separate origin. Thus, for example, an XSS payload can be placed in an SVG document.

In Jupyter Notebook before 5.7.8, an open redirect can occur via an empty netloc. This issue exists because of an incomplete fix for CVE-2019-10255.

An Open Redirect vulnerability for all browsers in Jupyter Notebook before 5.7.7 and some browsers (Chrome, Firefox) in JupyterHub before 0.9.5 allows crafted links to the login page, which will redirect to a malicious site after successful login. Servers running on a baseurl prefix are not affected.

An XSSI (cross-site inclusion) vulnerability in Jupyter Notebook before 5.7.6 allows inclusion of resources on malicious pages when visited by users who are authenticated with a Jupyter server. Access to the content of resources has been demonstrated with Internet Explorer through capturing of error messages, though not reproduced with other browsers. This occurs because Internet Explorer's error messages can include the content of any invalid JavaScript that was encountered.

Jupyter Notebook before 5.7.1 allows XSS via an untrusted notebook because nbconvert responses are considered to have the same origin as the notebook server. In other words, nbconvert endpoints can execute JavaScript with access to the server API. In notebook/nbconvert/handlers.py, NbconvertFileHandler and NbconvertPostHandler do not set a Content Security Policy to prevent this.

Jupyter Notebook before 5.7.2 allows XSS via a crafted directory name because notebook/static/tree/js/notebooklist.js handles certain URLs unsafely.

In Jupyter Notebook before 5.4.1, a maliciously forged notebook file can bypass sanitization to execute JavaScript in the notebook context. Specifically, invalid HTML is 'fixed' by jQuery after sanitization, making it dangerous.

A vulnerability in IPython allowing maliciously forged file to be opened for editing that could execute javascript code, specifically by being redirected to /files/ due to the mistakenly treating the file as plain text. Versions >= 3.0 and <= 3.2.1 of IPython are affected.

Upstream patch:

https://github.com/ipython/ipython/commit/0a8096adf165e2465550bd5893d7e352544e5967

CVE request:

http://seclists.org/oss-sec/2015/q3/558

A flaw was found in IPython's notebook handling:

Local folder name was used in HTML templates without escaping, allowing XSS in said pages by carefully crafting folder name and URL to access it.

Original report:

http://seclists.org/oss-sec/2015/q3/474

Upstream Patches:

3.x: https://github.com/ipython/ipython/commit/3ab41641cf6fce3860c73d5cf4645aa12e1e5892 4.0.x: https://github.com/jupyter/notebook/commit/dd9876381f0ef09873d8c5f6f2063269172331e3 4.x: https://github.com/jupyter/notebook/commit/35f32dd2da804d108a3a3585b69ec3295b2677ed