[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