[mosh-devel] Concerns about mosh's security at the Broad Institute

[Keith Winstein]

Hello Hayden,

The thread seems to have run its course -- do you have enough to proceed,
or how can we help you move forward?

Best regards,
Keith

On Fri, Aug 7, 2015 at 4:33 PM, Hayden Metsky <hayden at mit.edu> wrote:

> Hi,
>
> A friend (Simon Ye, CC'd) and I are PhD students at MIT who are
> currently working at the Broad Institute (a genomics center) using
> their computing infrastructure. The standard workflow is to use ssh to
> connect to a login server and then do work on that. This login server
> is accessible from anywhere (including outside the VPN) and password
> is the sole method of authentication.
>
> We would like the Broad Institute's IT staff to unblock UDP ports
> 60000-61000 so that we can use mosh to connect to the login servers.
> (We've both used mosh elsewhere and loved it.) Unfortunately we've
> encountered resistance from the security team, who have cited a number
> of security concerns. We've responded to many of these concerns but
> have made little progress. Of course, the security team's view is
> going to be biased in a conservative direction.
>
> Since networking and computer security are well outside our area of
> expertise, we think it would be helpful to pass the concerns along to
> mosh's developers. We would love to hear your thoughts; obviously we
> would welcome rebuttals, but we would also be happy to hear if you
> think the concerns have validity.
>
> Below I am going to quote six concerns verbatim from a document
> written by the security team. Under some of these concerns I'll
> include a short note from myself giving our thoughts.
>
> * "Mosh requires opening UDP ports on the Broad perimeter. That makes
>   the Broad network available as a participant in a DDoS performed
>   against external entities, specifically ICMP PORT UNREACHABLE class of
>   attack ("Smack" is one productized version). Even unwitting
>   participation by the Broad in a DDoS could have materially damaging
>   effect upon the Broad as a whole and the outcome of such an event
>   would inevitably involve closing the ports anyway."
>    - This is the team's primary concern. Our initial thought is that it
>      is difficult to imagine a single machine (server or router) having
>      a meaningful impact in a DDoS amplification, but perhaps this is
>      mistaken. Or maybe it is possible to use mosh with restrictions on
>      outgoing traffic that would avoid the Broad from participating in
>      this kind of attack? Even though this is not specific to mosh, we
>      would very much appreciate your thoughts.
>
> * "Mosh is based on the experimental MIT State Synchronization Protocol
>   (SSP). SSP is not know to any commercially available firewalls or
>   perimeter devices, so the use of mosh would not be manageable. Also
>   the first UDP mosh packet is from client to server. That underscores
>   the fact that there is no way for a firewall to have any control of
>   state."
>
> * "Both Google and Mozilla have rejected mosh."
>    - I don't know about Mozilla, but my understanding is that this is
>      incorrect with regard to Google. Even if Google only allows mosh
>      access from within a VPN and we're asking the Broad to allow access
>      from outside (ssh is allowed from outside), it is difficult to see
>      how this is an argument against mosh.
>
> * "Mosh sends the session key as an environment variable. User-
>   controlled environment variables are an injection path - their use
>   for sensitive purposes opens security vulnerabilities."
>
> * "Mosh requires server-side modification to /etc/sshd_config to enable
>   'SendEnv LANG LC_*'; this is turned off by default to protect against
>   environment variable injection."
>    - There's a lot that's misleading or incorrect about this. First, I
>      think they mean 'AcceptEnv' rather than 'SendEnv'. On many OS's,
>      it is my understanding that this is actually turned *on* by default.
>      When I run 'ssh broad locale', I receive back my laptop's locale
>      (even after changing it), indicating that the server is accepting
>      my LANG/LC_* env variables. So I suspect this is in fact turned on
>      (I cannot read the file). Regardless, we're able to install mosh
>      and use it internally among nodes, which we believe suggests that
>      no changes need to be made (besides unblocking ports).
>
> * "The mosh client can, at startup, invoke any program on the server.
>   The program does not have to be the mosh-server. So it is an
>   unrestricted and unmonitored remote execution environment like rsh."
>    - We're a bit confused on this point. The same (we believe) is true
>      of ssh, and since mosh authenticates via ssh we don't quite see how
>      this might be held against mosh given that ssh is already used.
>
> Thank you all so much for looking at this!
>
> Best,
> Hayden
>
> _______________________________________________
> mosh-devel mailing list
> mosh-devel at mit.edu
> http://mailman.mit.edu/mailman/listinfo/mosh-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/mosh-devel/attachments/20150812/72aba6e7/attachment.html