[IPython-dev] Some Thoughts on Notebook Security

[Matthias BUSSONNIER]

Long response to many messages.

tl;dr :
 lots of good idea, some misconception, a few good point raised.

Le 11 déc. 2012 à 02:48, Carl Smith a écrit :

> A static notebook is just a webpage, so it should ideally behave like
> one. Any webpage can execute arbitrary JavaScript, so the fact that
> static notebooks have this ability is not a concern in itself.


I think it is. In nbviewer we would like to allow people to comment, 
which obviously require them to be logged in… so it is not **exactly** static.

> Static notebooks, served from a different domain, could be rendered
> inside iframes, enabling us to embed them inside other webpages and
> applications. These notebooks would still be superficially served by
> our own servers, so the UX wouldn't be effected.

keep in mind that iframe are not sandboxed, and you can inject js on parent frame. 
Unless you use the sandbox attributes, which is part of html5 but not implemented in every
browser… And not yet infallible, it is more a "we'll help you embed other pages by providing a separate 
js namespace but we don't guaranty yes that the VM is unbreachable"


> I don't have much to say about kernelled notebooks right now, but on
> statics, I'd like to ask: If we serve a static notebook from a domain
> which has zero features beyond hosting static notebooks, would those
> notebooks be able to do anything to a user that a regular webpage
> couldn't? I'm not a security guy, so I really don't know, but it seems
> that we'd be totally free to let users publish whatever they liked,
> with no more restrictions than browsers impose already.

We still have some responsibility of what is displayed.

Responsible disclosure don't want to say much more but but having a statically display 
notebook is often link to having a "sharing/import" button which is dangerous.
And could lead to self propagating notebook through account that can infect other 
notebooks, or share itself on twitter...


> The main point is that we gain nothing by trying to cripple and
> sanitise JavaScript in notebooks. I think??

I know that Brian does not agree with that, but I am on your side with this point.
Except that preventing javascript might force people to do things "the right way".
This will lead to project that will still works across IPython version, whereas displaying JS have great chance to break.


> To fix this, we need to disable the Javascript representation of
> objects altogether.
> Unless I am misunderstanding the nature of the security risks, I think
> this is what we should do.


I disagree with the direct implication, but agree with the fact that disabling javascript repr can be done and will lead to cleaner code.
Flaws are **not** in repr. Flaws are mostly in assumption made on ipynb as a format and our html frontend.   And please stop considering that the "ipython notebook" is 
the only tool that generate ipynb files and use them.

We really have to choose a more appropriate vocabulary to speak of 
* ipynb as file
* ipynb as a format
* A notebook as the repr of a given ipynb files view throughout **our** html frontend.
* **Our** notebook server.

We should **not** consider that danger come from html/js repr but from **forged** ipynb file.

I challenge you to find a PDF generated from a tex file with pdflatex that trigger a breach in adobe reader. 
Anyone ?

Did anybody have a jpeg that came directly from his/her camera that trigger privileges escalation on windows ?
No ?

Corrupted mp3 that crash your computer from audacity ?

Do you consider that a script that ask for your root password is a virus/malware.. ?

Example :

#!/bin/bash 
sudo rm -rf  --no-preserve-root /

No, you just give the ability to do anything, you just make the ability to do bad stuff painful.
So my take on this one is :

Allow javascript only if:

server is **started** with some painfull flag  --yes-i-know-what-i-do-i-want-to-enable-js-in-output
When Js arrives to **frontend** in an output (see i didn't  tell where it came from… it could be at load time)
If the above flag has been set, 
	modal dialog 
		"something want to display js, allows for this session ? " (5 sec count down for before ok button becomes clickable.)

> Regardless of the approach taken, I think that Carl's suggestion of using separate domains for viewing & editing notebooks should be taken to heart.  It does help eliminate one vector of attack.

Multi domain is a real good idea. I have a clear view in my head on how we could use that in a way close to OAuth to allow javascript by still having "logged-in" users.
It wouldn't be as seamless a something like github, but close.

> But am I not correct that with the measures I proposed, that attack
> vector is also rendered null?  I don't want to have to tell people -
> you have to run multiple domains when using the notebook.  In many
> cases, people ar running the notebook without any DNS whatsoever…

The **big** question is:
Are viewer logged in (in any way) to the given server, and if so do they have the right to do anything else with those credentials ?
If it is just a public notebook viewer, then it's fine.

If you want something more "interactive" (sharing/ permissions…etc, and the display any JS ) you won't have much choice.
Or you will have a painful multi-login.

In any way this I thing should not diminish the fact that we should tell IPython notebook user to only 
view and even more download ipynb files from people they **trust**.

One good plugin for IPython notebook might be gpg-notebook-signing and chain of trust.


> It appears that IPython.core.display.HTML() allows <script> tags in the 
> html the user submits:
> 
> import IPython
> IPython.core.display.HTML('<script>alert("hi")</script>')

Yes this the issues are that in particular **those** are executed at load time.

To conclude I would say that Nobody did bring the question of security while collaborating, which is a much more difficult question.

also I've already written some stuff on js/security in IPep 3, feel free to complete or even make it  a separate IPep only focused on security.

https://github.com/ipython/ipython/wiki/IPEP-3:-Multiuser-support-in-the-notebook


Cheers.
-- 
Matthias

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20121211/7122d42f/attachment.html>