Closed Bug 770340 Opened 12 years ago Closed 12 years ago

please install mosh on people.mozilla.org

Categories

(mozilla.org Graveyard :: Server Operations, task)

task
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: tbsaunde, Assigned: kang)

References

Details

it should be useful when on a slow conection.

I tried to build this in my home dir and descovered g++ and autoreconf were not available, they might be useful to install for others in the future.
Assignee: server-ops → gdestuynder
Hi,

We have had a look at mosh in the past (Operations security), and those were our concerns:

- it requires a large range of open high ports on UDP on the firewall (it means we have to leave those ports open, facilitating communication to the outside for rogue processes, those can be spawned by any user)
- if we restrict using those open ports to the IP that logged in SSH previously (with a timeout and via conntrack or a similar module), this breaks mosh auto reconnect feature, which is most useful across mobile links
- it stores the session key in an environment variable (which may be risky, for example if you capture and replay an old session after compromising the machine)
- it is very new and while the authentication is done via SSH, past that, it's 100% handled by mosh, using a custom and entirely new implementation.

For a service as critical as SSH, while we would like to improve the latency in certain cases, it is not yet an option security-wise.

As the program is still very new, we hope that in the future some of the concerns will be addressed, so that we can look at it again.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WONTFIX
> - it requires a large range of open high ports on UDP on the firewall (it
> means we have to leave those ports open, facilitating communication to the
> outside for rogue processes, those can be spawned by any user)
> - if we restrict using those open ports to the IP that logged in SSH
> previously (with a timeout and via conntrack or a similar module), this
> breaks mosh auto reconnect feature, which is most useful across mobile links

ok, I take it your concerned about what the results of a compremise can be here?

> - it stores the session key in an environment variable (which may be risky,
> for example if you capture and replay an old session after compromising the
> machine)

isn't this the same as a ssh agent, which I would expect almost everyone uses.

> As the program is still very new, we hope that in the future some of the
> concerns will be addressed, so that we can look at it again.

yeah, its not a big deal, I can just put another machine in the middle.
SSH agent is not actually recommended to use by default, and, no, it's not exactly the same.
The agent store the path to the agent in the environment. The agent itself is protected by Linux's DACL.
The problem with the SSH agent is that if you compromise a machine an agent is connected to, you can use that agent as long as it is connected. It is ok to use the agent as long as you understand the above, and thus, don't use the agent by default.

There is a small patch I made that notifies you when you agent is used due to the above issue, but it doesn't have any easy installer (it's just a patch). If you're interested you can contact me about this on IRC/email.

With mosh, the session key is stored in the environment. If you compromise that account or get the environment (eg via another program) you can decrypt the entire session (else, you'd need something similar to read the pty or process memory and you can't replay old sessions).
From infra-all@m.c (:dustin) as I though it was a good summary, and it's easier to link people to this bug. Note that "many" have root access (or equivalent access via other users), as in "many in IT". Regardless,due to the sensitive data regularly sent, transiting through Mozilla servers, and the frequency of full root compromise local kernel exploits in Linux, my concerns are similar for any account.

Using OpenVPN+SSH has been providing me with a "close enough" experience without having to use auto-ssh, as well (instant reconnect and doesnt care if ip changes. its just missing the typing prediction really). Anyhow, we'll revisit mosh regularly as this question is asked regularly, and the program is actively developed.  Note also that many of these concerns are opened as bugs here: https://github.com/keithw/mosh/issues 

----- Original Message -----
> Mosh is amazing.  I've used it over dodgy wifi and terrible cellular
> connections in both Bangalore and rural Australia (right now,
> actually),
> and it works a treat.  I highly, *highly* recommend it.

..but only for recreational SSH or in desperate times.

Dumitru linked to the security-review bug for this tool.  It has a few "questionable" practices, such as hiding its AES key in an env var, and likely some additional vulnerabilities that become apparent after a more in-depth analysis.  Bear in mind that it's running a shell over UDP *without* checking the source IP, so it's trivial for anyone to inject ciphertext into the stream.  This opens up possibilities for replay attacks, timing attacks, chosen-ciphertext attacks, and so on.  Does it rate-limit invalid packets?  How much processing does it do on such a packet, and could this be used to DoS a target host?  Do invalid packets get a response, allowing reflector attacks and easy port scanning?  This is just off the top of my head - I'm sure someone with some actual security background could ask far more worrisome questions.

The security of SSH is one of the keys to the kingdom at Mozilla - after all, many of us can use our private keys to get root on hosts that have 100% open access to every system in the enterprise.  Best not to assume the new shininess is up to that level of security.
Product: mozilla.org → mozilla.org Graveyard

Hello,
Since it's not been closed/wontfix/resolved, can we take a look at mosh based access to mozilla servers again?
It' s been 4 years on so maybe things have improved?

You need to log in before you can comment on or make changes to this bug.