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": [ "" ] }
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
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.
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.
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 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).
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 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
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.
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.
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.
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.
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
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.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.
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.