Is scp unsafe? Should it be replaced with sftp?

Question

I have over 20 years experience in Un*x, and I have been using scp for immemorial times. scpis over SSH, therefore I consider it as secure as the latter. Now, in my company, where I recently took up a job, the Security Officer says that scp should not be used, because it is unsafe and obsolete. sftp should be favoured over it (yet over SSH too...)

I don't immediately agree with this, based on the infrastructure underneath scp, and based on how popular and trusted scp is in the professional community, and among my other colleagues from my ex-companies. I don't want to change my mind just because some CSO said it.

• This said, is there here a subject?
• Is scp suddenly the blacksheep?
• Is is just a mere security expert debates in higher spheres?
• Or is scp just good to use?

Answer 1

It's marginally "unsafe"

It was marginally "unsafe" before the addition of scp -T in OpenSSH 8.0 and it still is marginally "unsafe" when using scp -r.

Like other answers have stated, claims that scp is unsafe come from the client's previous inability to verify that it's receiving what it requested. The reason why scp couldn't verify is because the request is made using shell code running in the server's environment (with the server's state).

For example, let's say that the server's shell is set to zsh with extended glob, and I have my project directories set as zsh dynamic named directories for quick access. If I want to get a file from Rails project foo, I could get it with:

scp server:~foo/config/database.yml .

zsh on my server expands ~foo to ~/work-for/client/$client_name/foo.

If I want to get the server's 10 newest regular files, I could do:

scp server:'*(.oc[1,10])' .

If the server has plain bash, I could do:

scp server:'$(ls -t | head -10)' .

If I wanted to get the files that contained a pattern foo in their content, I could do:

scp server:'$(grep -l foo *)' .

There's just no way for the scp client to verify these kinds of requests that use shell code. However, it is a concern that it enables a malicious server to respond to:

scp -r server:foo/ ~

with overwriting .ssh/authorized_keys. In the eyes of scp, foo/ is server shell code that will evaluate to who knows what.

Enter scp -T:

-T Disable strict filename checking. By default when copying files from a remote host to a local directory scp checks that the received filenames match those requested on the command-line to prevent the remote end from sending unexpected or unwanted files. Because of differences in how various operating systems and shells interpret filename wildcards, these checks may cause wanted files to be rejected. This option disables these checks at the expense of fully trusting that the server will not send unexpected filenames.

To summarize, the previous default behavior of scp was moved to -T, and now the default is to check what's being received, using the provided argument as a simple pattern, when one's not doing a recursive copy. I believe it recognizes simple globs and escapes (looking at the source, it uses fnmatch(3) for the matching, with flags set to 0). In other words, it behaves more predictably when you're not looking to take advantage of its unique ability to specify files by shell code.

So now, if you don't use -T and you don't use -r, the only way to overwrite stuff like .bashrc is to ask for it explicitly. If you want to use shell code, you'd have to use -T at the expense of trusting the server:

scp -T server:'*(.oc[1,10])' .

So now you get the safety in the simple, non-recursive cases without completely giving up the unique ability that makes scp more useful than other utilities like sftp or rsync.

Can scp be replaced by sftp?

sftp can't specify the files it wants with shell code. It only accepts actual file paths. It's more limited that way. If you only needed scp for simple filepaths, then yes. However, if you want the added power of being able to specify the files from a simple command with server-side shell code (albeit at the expense of having to trust your server), then I think your only choice is scp.

Why the quotes around "unsafe"?

It was unsafe, but only when you wouldn't trust the server to not be compromised. In my case, and perhaps for the majority of people, we use scp with servers that we completely trust in other ways anyways. In particular, I use it to login from my laptop to my desktop or vice versa. If we can't trust our own devices, then what can we trust? That's why I think calling it just plain unsafe is hyperbolic. It's not comparable to how we call telnet unsafe, for instance.

I still appreciate the change to requiring -T, though. It is safer. Also, it's certainly true that for those people that don't need the features enabled by -T, there really isn't much advantage in using scp over sftp or rsync.

Answer 2

The way I read it is, "it depends".

According to CVE-2019-6111

However, the scp client only performs cursory validation of the object name returned (only directory traversal attacks are prevented). A malicious scp server (or Man-in-The-Middle attacker) can overwrite arbitrary files in the scp client target directory. If recursive operation (-r) is performed, the server can manipulate subdirectories as well (for example, to overwrite the .ssh/authorized_keys file).

So if scp goes between hosts on your premises (datacenter), it is likely (but not certain) than no MITM attack can be performed.

However, if you fetch business files from a customer/partner over the world wild web, you should rely on sftp, or better, ftps. (At least, ensure that the scp client and ssh server have proper versions)

Answer 3

I'd say a lot of Unix commands become unsafe if you consider a MITM on SSH possible. A malicious sudo could steal your password, a malicious communication client could read your mails/instant messages, etc.

Saying that replacing scp with sftp when talking to a compromised server will somehow rectify the situation is very optimistic to say the least. Whatever damage scp can do to your local files can also be done from a binary file, shell script, Python file, Makefile, etc., and a rogue sftp will happily serve you these.

In short, if you don't pay attention to which servers you SSH into, there's a high risk for you to be screwed no matter which tools you use, and using sftp instead of scp will be only marginally safer.

This isn't to say that switching to sftp is a bad idea: if it's a superior tool for the task at hand, then you have a good reason to switch, which is, incidentally, not related to security.

Answer 4

There's a lot of confusion about the new OpenSSH changes to scp made in response to CVE-2019-6111, and how safe they're supposed to make everything.

Their purpose is to prevent a rogue server used as source for the files from sending other filenames than requested, and overwrite random files on the local machine.

But they have no effect when the -r option is used. Using -r implies -T.

While perfectly logical, many people would fail to realize it, and they will be lulled in a sense of complacency by always expecting scp to check the filenames. Until they meet the hard truth, one day. The "security" offered by this is no better than alias rm='rm -i'.

Since it can be pretty convoluted to set up a rogue ssh/scp server just for testing, you can use the -S program option of scp (which directs it to use another program than ssh to set up the channel) to verify my claim.

Here I'm using a small executable script ssh_from_hell, which, no matter what asked for, always sends a lolcats.lol file:

$ chmod 755 ssh_from_hell
$ scp -S ./ssh_from_hell user@host:foo.txt .
protocol error: filename does not match request
    # OK, as expected

$ scp -S ./ssh_from_hell -r user@host:foo/ .
lolcats.lol                                   100%   12    62.0KB/s   00:00
$ cat lolcats.lol
LOL LOL LOL


$ cat ssh_from_hell
#! /usr/bin/perl
use strict;

$|=1;   # autoflush
sub readack { local $/=\1; <STDIN> }
sub ack { print "\0" }
my $data = join '', <DATA>;

readack;
printf "C%04o %lld %s\n", 0666, length($data), "lolcats.lol";
readack;
print $data;
ack;

__DATA__
LOL LOL LOL

---

Another infelicity brough about by the new changes is the fact that you can no longer quote the remote filename, instead of

scp 'user@host:"a file with spaces and * love *.txt"' .

you should use

scp 'user@host:a\ file\ with\ spaces\ and\ \*\ love\ \*.txt' .

However, some influential developers apparently love braces, so they have also added an ad-hoc pattern matching implementation with braces support to scp -- they could've probably used glob(3) with GLOB_ALTDIRFUNC|GLOB_BRACE, but it's always more fun to write new code. Anyways and fwiw, notice that the brace expansion implementation in scp is almost csh-like ie. {{foo}} will expand to foo:

$ scp -S ./ssh_from_hell 'user@host:{{lolcats.lol}}' .
lolcats.lol                                   100%   12    61.6KB/s   00:00

Yet not exactly the same as that from csh, perl and glob(3):

$ scp -S ./ssh_from_hell 'user@host:lolcats{}.lol' .
protocol error: filename does not match request

And also buggy:

$ scp -S ./ssh_from_hell 'user@host:lolcats{,}.lol' .
protocol error: filename does not match request

Answer 5

man scp

scp copies files between hosts on a network. It uses ssh(1) for data transfer, and uses the same authentication and provides the same security as ssh(1). Unlike rcp(1), scp will ask for passwords or passphrases if they are needed for authentication.

You asked is scp unsafe? It can be, just like anything else not set up and used properly.

Man in the middle (MITM) vulnerability, you know that initial popup you get the first time ssh'ing to somewhere, the one you ignore and just click ok on...

the server's host key is not cached in the registry. you have no guarantee that the server is the computer you think it is. The server's ssh fingerprint is blablabla.

It is not SSH's (or scp's) fault. It is yours for not using the protocol properly.

Once you have established the ssh server your connecting to is who it's supposed to be, then it is a simple matter of (in my opinion) of using SSH protocol 2 and AES-256 cipher. That is the bulk of your security; if you don't tailor your sshd_conf (and the client ssh_config) and leave it defaulted then that's on you.

here's an except of an sshd_config you can ponder over

Protocol                                     2
Ciphers                                      aes256-ctr
MACs                                         hmac-sha2-512,hmac-sha2-256
# MACs                                       hmac-sha1
PermitRootLogin                              no
AuthorizedKeysFile                           .ssh/authorized_keys  {set this up}
IgnoreRhosts                                 yes
IgnoreUserKnownHosts                         yes
StrictModes                                  yes
UsePAM                                       yes

---

according to CVE-2019-6111

the scp client only performs cursory validation of the object name returned (only directory traversal attacks are prevented). A malicious scp server (or Man-in-The-Middle attacker) can overwrite arbitrary files in the scp client target directory. If recursive operation (-r) is performed, the server can manipulate subdirectories as well (for example, to overwrite the .ssh/authorized_keys file).

that is taken out of context. Don't connect to a malicious ssh server in the first place. Don't blame SSH for someone exploiting the protocol setting up their ssh server to overwrite arbitrary files in the scp client target directory. Make use of the server/client keys to establish the SSH connection properly in the first place and there's no MITM malicious server.

scp, which is ssh, is safe. Saying scp is not safe is inherently saying ssh should not be used because ssh is unsafe and that is not true.

SSH = secure shell

scp = secure copy over SSH

ftp = file transfer protocol

sftp = SSH ftp

ftps = ftp over TLS/SSL

Should scp be replaced by sftp?

when you can't be bothered by with the server's host key/fingerprint and just click ok, ask yourself how then is that ok with sftp (connecting to a server you have no guarantee is who you think it is).

once the SSH communication tunnel is established between two points, properly, the semantics of communication within be it secure copy or the file transfer protocol is trivial at that point. scp, which is ssh, is safe. Saying scp is not safe is inherently saying ssh should not be used because ssh is unsafe. And that is not true. If I call you on the phone, and you cause bad things to happen on my end, that's not the phone company's fault.

"The scp protocol is outdated, inflexible and not readily fixed. We recommend the use of more modern protocols like sftp and rsync for file transfer instead."

pleeeasssee.... rsync performs no encryption on its own, and you run into the same problem of no guarantee who you connect to is who you think it is. But in this insinuation rsync gets a pass? Careful of where you take recommendations from.

Answer 6

They are not correct you are!

sftp is a derivative of ssh. I think he meant to not use FTP and use sftp.

SCP and sftp are running on top of SSH for the most part so if they want you to not use SCP they shouldn't want you to use SSH either (or sftp for that matter). Both sftp and scp allow secure file transfers, encrypting passwords and transferred data.

sftp can do some things that scp cannot but not security related as far as I know

Also SCP is faster than sftp is it uses a faster algorithms.

Links that show sftp is a derivative of ssh.

https://www.linux.com/tutorials/transfer-files-securely-sftp/

https://www.goanywhere.com/blog/are-ssh-and-sftp-the-same https://www.technology.pitt.edu/security/secure-shell-ssh-and-sftp