Reading

> Malicious scp server can write arbitrary files to scp target directory

looks like you don't need to `cd /tmp` before running scp, it's enough to scp _to_ a freshly created directory (`scp host:file /tmp/dir1`), inspect its contents and `rm -rf /tmp/dir1` afterwards.

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).

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.

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).

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.

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

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.

> The attacker controlled server [...] drops .bash_aliases file to victim's home directory when the victim performs scp operation from the server. The transfer of extra files is hidden by sending ANSI control sequences via stderr. [...] Once the victim launches a new shell, the malicious commands in .bash_aliases get executed.

Sounds to me like everything the user executing the scp command can access can be compromised.

> The attacker controlled server [...] drops .bash_aliases file to victim's home directory

This can only happen if scp is invoked from the home directory (or from root or /home).

The server could also drop a "ls" file with execution rights in current directory. If "." is in your path before /usr/bin (I have already encounter that), it may be called as soon as you type ls (generally just after the scp).

Sure, it can also drop filenames starting with a dash, filenames with spaces/newlines in it and all sorts of stuff. These can cause all kind of havoc in poorly written scripts. Having "." in your path is an obvious misconfiguration too.

Having a trailing : at the end of the PATH is the same as :. and occurs quite often.

That example requires the user to copy something to the home directory. If you copy something to /tmp, or to a subdirectory of your home directory, that attack is not possible (according to my understanding)