[korpiq]

I read it as being MitM and manipulating target (final, originally intended server) directories and files only, and in addition to spoof output to client to hide the fact it's doing so. In that case it does not matter where you run the client.

What makes MitMs possible is that checking fingerprint of new host is left to user. Instead we should have processes to automatically 1. acquire via other means and add fingerprint of each new target host 2. verify new host fingerprints with a separate party (central server or a ring of trusted buddies).

[jakobegger]

There is already a solution to this problem, which is host key certificates.

All you need to do is configure your SSH client to accept only host keys signed by your CA.

However, setting that up is complicated. You need a lot of knowledge to set that up securely. On the other hand, manual verification of host keys is trivial -- anybody can compare a short string of characters.

[h1d]

Trivial but who does that when? I never even learnt what I should compare that with and just accepted everything (and have been safe that way).

[isodude]

The best way to ensure that keys are correct, is to git a file like .ssh/known_hosts2 and add known keys to that file before you connect to the server.

How you get the public key is up to you, but they are located in /etc/ssh/ on the server, or given to you when creating the server.

ssh-keyscan can scan a host and print the keys as well.

If you also add the servers to .ssh/config you also get tab completion.

It takes a bit more job to do, but it feels much safer afterwards, and it's a good routine.

[da_chicken]

Your solution is that a system you trust is impossible to compromise? That seems unreasonably optimistic.

[Thorrez]

If you let a something MITM you it will always be able to steal your files, no path validation will fix that. If you let something MITM you when copying files from client to server it should have no way of changing the destination directory (assuming you authenticate using asymmetric crypto), regardless of path validation. This vulnerability has nothing to do with that.

This vulnerability is only about copying files from the server to the client, and lacking path validation when that happens. This problem can be fixed without fixing MITM.