CVE-2021–32797 and CVE-2021–32798 Remote Code execution in JupyterLab and Jupyter Notebook

TL:DR; All recent JupyterLab and Notebook versions are susceptible to a attack where a maliciously crafted notebook can trigger arbitrary code execution when a user views these malicious files.

We strongly advise all users to deploy the new version of JupyterLab and Jupyter Notebook.

Jupyter Notebook 6.4.1 or above, 5.7.11 or above.

Jupyter Lab 3.1.4 or above, 3.0.17 or above, 2.3.2 or above, 2.2.10 or above , 1.2.21 or above

This blog post will be updated with links to the various patches, exploit and disclosure later once the final links are available.

Jupyter Security Model

Jupyter Notebook act as a REPL (Read Eval Print Loop) in a browser, our main goal is to expose as many functionalities to our users, with the least restrictions. We also want users to be able to share their results with other, and let everyone be capable of reproducing the result.

When receiving an untrusted notebook from a potentially malicious source we still want users to be able to inspect a notebook without risks, our approach is that an untrusted notebook has restrictive capabilities until all cells have been manually inspected and explicitly run by a user, or the notebook is explicitly marked as trusted. If one finds a way to bypass this trust mechanism, a notebook might be able to execute code in the browser at at a time where a user is not expecting execution to occur.

This is what happen in these particular CVEs, where some content of a notebook were improperly handled.

[This part of the blog post will be updated with links to actual reports, and proof of concept once the patched version have reached enough package repositories]

CVE Timeline

We want to thanks Guillaume Jeanne (Google), and Timo Schmid (Google) for the vulnerability report and helping us through the fixing process.

• Thursday, 15 Jul 2021 07:11:13 -0700 (PDT): Initial question about security issue disclosure on security@ipython.org (no specific on the vulnerability)
• Tuesday, 20 Jul 2021 05:52:09 -0700 (PDT): Actual Vulnerability Report.
• Tuesday, 20 Jul 2021 : Open relevant GitHub security advisory on Notebook and JupyterLab Repositories
• Thursday, 5 August 2021 : First releases with patched version on PyPI.
• Monday, 9 August : publication of this blog post and publish security advisory on GitHub.
• [Further item may be added to list publication by downstream repositories, like conda, conda-forge, debian…, contact us to add an item]

What we learned

Dealing with Security vulnerability in Jupyter and more generally in Open-Source is far from easy. We initially thought about treating the Notebook and Lab CVE separately but they are/were too similar and the cross discussion too revealing to treat both independently.

As Jupyter is mostly a volunteer based organisation, there is often no contributor responsible to replying to security issues, and when someone steps up they might not be a expert, nor available all the time. I want to give special thanks to Steve Silvester (Apple) , Afshin Darian (Two Sigma), and Zach Sailer (Apple), and Matthias Bussonnier (Quansight) for writing the fixes, planning through the release and notifying stakeholders.

Advance notice to stakeholder is complicated, we know of a few large deployment and have personal connections to a couple organisation, and were able to reached out to let them know critical release would be published. There is an inherent tension between publicly warning our user base that security release would be published, which might push malicious actor to closely survey the codebase changes and re-derive the attack vectors, and publishing the release first, with the details later. Especially since we are trying to be transparent in our communication, security fixes are the opposite of our normal communication workflow.

Our communication process is imperfect. We have 2 mailing list for security-related discussion. The first one – security@ipython.org – has only a couple of members all core contributors and can receive email from the outside, it is used for triage. It receive a high number of spam as this is public email. As it has only a few members and we are all busy, mail can slip through. The second mailing list is slightly larger, and used for internal announcement for stakeholder. It has a fairly open membership model, (ask a Jupyter developer if you can be on it, and the reason why and we’ll likely add you), though it’s content seem to be ignored (it even lands on my spam folder, not sure why).

What we’ll do better

In order to attempt to better react and be proactive with respect to security we are attempting to form and new security-focused subproject/workgroup to educate and have procedure for everything security related. We welcome your involvement and feedback in how to improve Jupyter security and how to better involve the community.