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

[Hayden Metsky]

Hi Keith,

The replies in this thread have been incredibly helpful and even more
than we had hoped for! Thank you to all!

Just this evening Simon and I put together a nice PDF summarizing the
responses (including a link to this thread) and sent
it to the Broad director of IT. We've met with him before and hope to
meet again, after he reads it, to further discuss Mosh. In case you
think this document would be helpful, I'm more than happy to share it
in private; I'll email it to you directly.

Thanks again! We'll absolutely be in touch if we think there are
additional ways you or Mosh's community can help us.

Best,
Hayden


On Wed, Aug 12, 2015 at 8:06 PM Keith Winstein <keithw at cs.stanford.edu>
wrote:

> 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/88c49ec6/attachment.html