Description

JupyterLab 4.5.0 enabled copying and pasing cells through the system clipboard. The paste path parses clipboard text as cell JSON and inserts the cells without clearing metadata.trusted, so a payload can declare its own output as trusted. JupyterLab does not sanitize a trusted output and evaluates the <script> elements it contains, so pasting the cell runs attacker's JavaScript in the JupyterLab origin. The same payload with "trusted": false is sanitized.

json [ { "celltype": "code", "executioncount": null, "source": "", "metadata": { "trusted": true }, "outputs": [ { "outputtype": "displaydata", "metadata": {}, "data": { "text/html": "<script>/ runs on paste /</script>" } } ] } ]

Users are affected if all of the following are true:

- they run JupyterLab 4.5.0 through 4.6.3, or an application that bundles it such as Notebook 7.5+; - if running 4.5.2 or newer, useSystemClipboardForCells is enabled - it is off by default in 4.5.2+, and always enabled on 4.5.0 and 4.5.1 with no opt-out - they run a Paste Cells command (e.g. from context menu, command palette, shortcut) while attacker-controlled text is in the clipboard; and - pasteCodeCellsWithoutOutput is off, the default, so the pasted cell keeps its outputs

Impact

The script runs in the JupyterLab page, in the same origin and session as the authenticated user, so it can call the Jupyter Server REST API as that user: read and write any file under the server root, start a kernel and run code in it, and open a terminal where terminals are enabled. It runs on paste, without the user executing anything.

Only the output of a code cell can run a script this way. Markdown and raw cells are always sanitized, as the trust documentation states.

The attacker needs no JupyterLab account and no access to the server, only the user's clipboard at the moment of the paste. A web page can replace the text you copy from it, or write the clipboard directly once you have given it permission. Both need you to click or press a key on that page first.

Patches

JupyterLab v4.6.4 and v4.5.11 contain the patch. Cells read from the system clipboard that cannot be traced to the current window no longer carry metadata.trusted into the notebook, so their outputs are sanitized like any other content of unknown origin.

Users of applications that depend on JupyterLab, such as Notebook v7+, should update jupyterlab package too.

Workarounds

On 4.5.2 and later, confirm that the system clipboard is not in use for cells. The setting is off by default; check Settings, Notebook, or the raw value:

json { "@jupyterlab/notebook-extension:tracker": { "useSystemClipboardForCells": false } }

With that setting off, cell copy and paste use JupyterLab's in-application clipboard, which never leaves the page. The cost is that cells can no longer be copied between browser tabs or windows.

On 4.5.0 and 4.5.1 there is no such setting, and every paste reads the system clipboard and upgrade is highly recommended.

Pasting cells without their outputs also stops the script from running, at the cost of discarding outputs on every paste:

json { "@jupyterlab/notebook-extension:tracker": { "pasteCodeCellsWithoutOutput": true } }

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