CVE-2019-6111 and other scp vulnerabilities
More recently (since about 1983), it turned out that OpenSSH, as the rsh heir, for the scp command (ex. Rcp) allows the server to choose which file and with which parameters to transfer to you. And the output vulnerabilities allow you to hide exactly which file you were transferred.
That is, you ask for file.txt, but you get - exploit.bin
And there are no fixes yet, such are the cases. Use sftp or rsync.
The scp client does not check for extra characters in the file name, which allows you to hide the real name of the file being transferred (for example, ASCII codes)
The scp client allows you to write to stderr and rewrite data in the terminal, which allows you to hide the real name of the file being transferred (for example, ASCII codes).
The scp client does not check which file is sent to it and does not compare it with what it requested. Malicious server can pour on the client all that he wants, and with any mode.
$ rm -rf * $ ls -la итого 36 drwxr-xr-x 2 user user 4096 янв 25 15:11 . drwx------ 99 user user 28672 янв 25 14:23 .. $ scp test@localhost:x.txt . x.txt 100% 32 0.3KB/s 00:00 $ ./exploit.sh # откуда он взялся?! You're hacked. Sorry for that Please upgrade your OpenSSH client $
In this example (a slightly modified exploit from the link above), the exploit.sh file with 755 permissions is loaded along with x.txt, and the fact of the transfer is overwritten with stderr.
In short, that's all. OpenSSH including 7.9p1, putty, winscp <5.13.
Only WinSCP (5.14+) has fixes.
Use sftp / rsync when working with untrusted servers.