Include MathJax by default or access the CDN over a secure connection

[leoluk]

IPython Notebook loads MathJax over an insecure connection by default. Code running within the IPython Notebook can, by design, execute code on the user's system. This leaves users vulnerable to MITM attacks.

Possible fixes (that I can think of):

• Always access the MathJax CDN over a secure connection (it support HTTPS).
• Custom loader which verifies the code against a local checksum (this would protect against a compromised CDN, but has some obvious disadvantages like complexity or the need to maintain a list of checksums).
• Ship local MathJax sources (undesirable because it's ~43MB?).

Related: CVE-2014-3429 / #4845

[minrk]

I think we can make it https by default. Is there any disadvantage to doing that?

We have considered shipping MathJax in components as well. It's not so bad as it seems, because MathJax doesn't need everything - it contains PNG and SVG fallbacks for fonts, which we can probably avoid shipping.

[Carreau]

It is https if server is runned over https (universal url that starts with //:).

[minrk]

That's true, but people don't generally bother to set up https on localhost, since it's a pain. Unless someone can come up with a reason, I don't know why we would ever use http to load mathjax from CDN.

[leoluk]

Might be a good idea to request a CVE for this (after all, it's easily exploitable - inject a JS snippet like IPython.notebook.kernel.execute("!xclock") and you've got instant remote code execution).

[Carreau]

Even on localhost you should not run over http any other user could sniff the traffic and log as you.
I'm fine with a CVE if you, but IMHO it is worthless to try to pretend page served over http are secure.

[takluyver]

Well, plenty of people use computers which don't have any other users, and then localhost is secure. Even in cases where you have other users, they're probably more trusted than people on coffee shop wifi.

[Carreau]

Well, plenty of people use computers which don't have any other users, and then localhost is secure. Even in cases where you have other users, they're probably more trusted than people on coffee shop wifi.

But http without auth, probably any other software even with sandbox can do http request to localhost and run code. Isn't there any way to, like signing generate a certificat automatically and serve over https by default ?

[takluyver]

Then the user has to acknowledge a massive warning about a self-signed certificate (which is silly, it's no less secure than http, but that's the way browsers are).

What might work is to enable authentication by default, and open the browser with a one time password to authenticate the user.

[rgbkrk]

@Carreau Right, the user shouldn't assume this makes it secure for them. We're trying to protect the lowest common denominator by default here. After all, don't most instructions just tell people to launch ipython notebook? That's what I do on a fresh box before laying down my default profile.

[leoluk]

Serving over HTTPS would not prevent malicious software running on localhost from connecting to the notebook and running code, unless you're using client certificates (which would be cumbersome as a default configuration). As far as I know, there's no real security benefit from using a secure connection on localhost. Sniffing traffic usually requires elevated privileges (at least on Linux - probably on Windows as well).

[rgbkrk]

@leoluk The scenario I outlined in chat was a router out of your control. Public wifi, cafe, etc. Change HTTP on demand. I've certainly used ettercap in the past in the netsec lab back at CSU to flip images and other tomfoolery. This is legitimate and thank you for bringing it up!

[leoluk]

@rgbkrk: Yeah, I tried this with mitmproxy and it worked perfectly fine. Kinda scary. Just imagine a SciPy conference/event where everyone is on a shared WiFi/sitting in the same subnet. You could probably compromise lots of machines just by ARP spoofing the network.

I like the idea of a one-time password/access token appended to the URI which automatically authenticates the user. This would prevent the aforementioned software in a sandbox from wreaking havoc, and reduce the attack surface (CSRF, XSS...).

[rgbkrk]

CVE discussion on the oss-security list: http://seclists.org/oss-sec/2014/q3/272