Channel: CodeSection,代码区,网络安全 - CodeSec
Viewing all articles
Browse latest Browse all 12749

Notebook 4.2.2: Security fix

TL;DR: upgrade to notebook 4.2.2

We just released notebook 4.2.2 with a few bugfixes and one important security fix.

We (specifically Steve Sylvester ) have found a longstanding security issue in the Notebook, regarding output of untrusted notebooks being able to execute code when the notebook is opened.

The vulnerability has been assigned the identifier CVE-2016-6524.

Affected versions:

2.0 ≤ Ipython < 4.0 (all IPython notebook versions, starting with the introduction of the concept of untrusted output) notebook ≤ 4.2.1


Upgrade to notebook 4.2.2


pip install --upgrade notebook or conda install notebook (once conda channels propagate the release)

If you cannot upgrade to 4.2.2, we have prepared a backported patch for the 2.x and 3.x branches of IPython, but have no current plans for making a new release of these branches.


The vulnerability was reported on July 26, and a fix proposed on the same day. After some review and testing of the patch and a check for similar vulnerabilities, on August 3 a CVE was assigned and the 4.2.2 release made immediately thereafter.

The goal of Jupyter notebooks is executing code, and outputs being able to execute code is one of the key features that enables people to do cool stuff. However, we don't want notebooks written by not-you to be able to execute code as you on your computer as soon as you open them. For this reason, we have the concept of 'trusted notebooks' (introduced in IPython 2), which are notebooks where all output has been produced by you. The main result is that if you get a notebook from someone else with fancy dynamic javascript output, you might see things like:

<Javascript uninteresting repr...>

instead of the fancy visualization. Once you either execute the notebook yourself or explicitly trust the notebook from the File menu, you can see the real results.

When loading output from an untrusted notebook, we take one of three actions:

the output is unsafe , and ignored (Javascript) the output is potentially unsafe , and sanitized (HTML) the output is safe , and displayed regardless of trust

It's that third option of "safe" outputs where things went a bit awry. Safe outputs should be outputs that cannot run code in the browser. This includes plain-text output, which we reliably escape, and raster images, such as pngs and jpegs. So far, so good. It also includes latex, which ought to be like plain text, in that it's properly escaped before being put on the page to be rendered by MathJax . This is where we went wrong. We were putting latex output on the page with jQuery's $.append , which puts elements on the page verbatim. In this way, if the output that claimed to be latex was actually HTML with script tags and such, it would be able to execute code. The right thing to do (all along) was to use the safe $.text , which escapes HTML entities before putting things on the page.

So that's the fix .

I'm a bit surprised that we didn't have bugs caused by inequalities and such in equations being mistakenly interpreted as HTML tags.

See our security docs for further details on the security model in Jupyter Notebooks.

If you find a security issue with the notebook or other Jupyter components, please let us know at[emailprotected]

Viewing all articles
Browse latest Browse all 12749