More on DNS rebinding

[Thomas Kluyver]

Google's 'Project Zero' security effort just disclosed a DNS rebinding vulnerability in at least one popular Bittorrent client. There's some interesting description which helps me understand how it works:

https://bugs.chromium.org/p/project-zero/issues/detail?id=1447
https://arstechnica.com/information-technology/2018/01/bittorrent-users-beware-flaw-lets-hackers-control-your-computer/

First off, I think this supports our decision to have token authentication enabled by default, even though it's inconvenient in some situations. As I understand it, this should prevent DNS rebinding attacks from taking any action that requires authentication.

Second, the fix Tavis Ormandy suggested for Transmission is interesting:

"""

I discussed this with a jannh, I think a good solution would work like this:

* If a connection is over the loopback interface, the hostname must match "localhost",
  "localhost.", "127.0.0.1", or "[::1]". This is the same list CUPS uses:
  https://github.com/apple/cups/blob/master/scheduler/client.c#L3752
* If a connection is not over loopback, allow any hostname iff auth is enabled.
* If a connection is not over loopback and auth is not enabled, require the user to
  create a whitelist of acceptable hostnames (They can specify * if they really
  really don't want security).
"""

Should we look at employing hostname whitelisting in addition to authentication, either as an
extra line of defence or as a convenience for users on localhost?

My leaning would be to do it as an extra line of defence; given how complex browsers are and
the fact that Jupyter is designed to execute arbitrary code, defence in depth makes sense.

Thomas

[Matthias Bussonnier]

Hi Thomas, 

Thanks for the heads up, this is  nice description. I think it's a good idea to add this extra line of defense, and a flag to disable it with a big warning, to give some people the time to upgrade the ability to update the notebook server without deploying a large change to their infrastructure.

Thanks !

-- 

Matthias

--
You received this message because you are subscribed to the Google Groups "Project Jupyter" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jupyter+unsubscribe@googlegroups.com.
To post to this group, send email to jup...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jupyter/CAOvn4qiNK_CrmtUx9rhwW%3D6zYu8meaPGDKE3C3pS4uhMc742MA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Damián Avila]

> My leaning would be to do it as an extra line of defence; given how complex browsers are and the fact that Jupyter is designed to execute arbitrary code, defence in depth makes sense.

I would be +1 on this.

Cheers.

To view this discussion on the web visit https://groups.google.com/d/msgid/jupyter/CANJQusWHdW4Cn8hC4iv_LN3%3DP8pRHdrLYasqmzBL_qwN357iVA%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Damián Avila

[Lawrence D’Oliveiro]

On Wednesday, January 17, 2018 at 4:44:38 AM UTC+13, Matthias Bussonnier wrote:

... and a flag to disable it with a big warning ...

I think a simple name like “enable DNS insecure mode” would do the trick. I don’t think big warnings are very useful: people just ignore them. But use a trigger word like “insecure”, and that should make them think twice. By all means link to a more detailed explanation elsewhere. But for those who can’t be bothered to read further, it should at least make them nervous.