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

Hayden Metsky hayden at mit.edu
Fri Aug 7 19:33:19 EDT 2015


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/mosh-devel/attachments/20150807/dba7809b/attachment.html


More information about the mosh-devel mailing list