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 <hay...@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@mit.edu
> http://mailman.mit.edu/mailman/listinfo/mosh-devel
>
>
_______________________________________________
mosh-devel mailing list
mosh-devel@mit.edu
http://mailman.mit.edu/mailman/listinfo/mosh-devel
