Jakub jelen (a Red Hat security engineer) suggested that the SCP protocol be classified as obsolete to later proceed to its elimination. As SCP is conceptually close to RCP and inherits architectural problems fundamentals that are the source of potential vulnerabilities.
In particular, in SCP and RCP, the server accepts the decision on which files and directories to send to the client, and the client follows the server's instructions and only checks the correctness of the returned object names.
By connecting to a server controlled by an attacker, the server can deliver other files, which has repeatedly led to the identification of vulnerabilities.
For example, until recently, the client only checked the current directory, but did not take into account that the server could issue a file with a different name and overwrite files that were not requested (for example, instead of the "test.txt" requested, the server can send a file called ». bashrc« and it will be written by the client).
In the post, published by Jakub Jelen, you can read the following:
Hello Fedora users! In recent years, there have been several issues in the SCP protocol, leading us to discussions whether we can get rid of it in the initial phases.
Most of the voices said they use SCP mainly for simple ad-hoc copies and because the sftp utility does not provide a simple interface to copy one or two files back and forth and because people are only used to write scp instead of sftp.
Another problem with the SCP protocol is the argument processing feature.
Since it is mentioned that when copying files to external server the file path is appended to the end of the scp command local, for example, when you run the command «scp / sourcefile remoteserver: 'touch / tmp / exploit.sh` / targetfile'» on the server, the command »touch / tmp / exploit.sh» and the file / tmp was created /exploit.sh, so it is important to use correct escape characters in scp.
When scp is used to recursively pass the contents of directories (the "-r" option) in file systems that accept the '`' character in file names, an attacker can create a file with apostrophes and make it the code to run.
In OpenSSH this problem remains uncorrected, as troublesome to fix without breaking backward compatibility, eg running commands to check if a directory exists before copying it.
Previous discussions have shown that scp is generally used to copy files from one system to another.
However, many people use scp instead of sftp due to simpler interface and obvious to copy files, or just out of habit. Jakub suggests using the default implementation of the scp utility, converted to use the SFTP protocol (for some special cases, the utility provides the "-M scp" option to revert to the SCP protocol), or adding a compatibility mode to the sftp utility which allows you to use sftp in as a transparent replacement for scp.
A few months ago I wrote a patch for scp to use SFTP internally (with the possibility to change it back using -M scp) and ran it successfully in some tests.
The overall upstream feedback was also quite positive, so I'd like to hear from our users as well. It still has some limitations (support is missing, it won't work if the server doesn't run the sftp subsystem,…), but it should be good enough for the most common use cases.
Between the limitations of the proposed approach, the impossibility of exchanging data with servers that do not start the sftp subsystem is mentioned, and the absence of a transfer mode between two external hosts with transit through the local host (mode "-3"). Some users also note that SFTP is slightly behind SCP in terms of bandwidth, which becomes more noticeable on poor connections with high latency.
For testing, an alternative openssh package has already been placed in the copr repository, patching it with the implementation of the scp utility over the SFTP protocol.