SCP support in RHEL
What is SCP
OpenSSH’s SCP (secure copy, remote file copy program) is a program based on the insecure RCP (remote copy) command-line API. It mimics its semantics and follows a similar logic as the cp command for local copy. The RCP protocol was designed in the 80s without security in mind and SCP even now does not provide enough input validation to be completely secure. The protocol is very flexible and some use cases depend on obscure shell expansions, quoting and quotes dropping, making its maintenance and future development very hard.
Vulnerabilities summary
In recent years, we fixed several vulnerabilities such as CVE-2018-2068 or CVE-2019-6111. These allowed a malicious server to modify the files on the client file system, but fixes for them, adding file-name validation, already broke some existing use cases. There is a newer CVE-2020-15778 without a released fix, causing possible command execution on a remote server by appending it to an scp command and we can expect more to come. Note that this is not a privilege escalation as scp requires remote command execution by design.
The patches for these vulnerabilities are usually breaking existing corner cases used for decades and therefore there is a very low chance of fixing them in existing RHEL releases where we retain backward compatibility.
Supported alternatives
In this regard, we cannot recommend using SCP anymore for our customers in new applications or scripts as a program to copy files remotely. Customers should consider using the SFTP protocol instead (implemented in the sftp binary or through the libssh library), which is well defined, does proper input checking and can grant more fine-grained permissions. The other possibility is using rsync with SSH transport for its simpler command-line API.
We are considering various options in addressing the SCP vulnerabilities problem in future RHEL releases.
5 Comments
I think is missing how to disable SCP and continue using ssh instead, maybe tcpwrappers will work?
There are not tcp_wrappers since RHEL8. I am not sure what are you trying to achieve. This talks only about SCP vulnerabilities and nothing about removing/disabling SSH. For the record, there is a follow-up article about RHEL9 deprecation of SCP which might also bring some answers to your questions: https://www.redhat.com/en/blog/openssh-scp-deprecation-rhel-9-what-you-need-know
What is the problem here (or at CVE-2020-15778)? As I read the details, it starts with an attacker with scp abilities. As far as I know, he needs an account on the remote machine that is allowed to scp. Since scp is part of ssh, the account needs to be allowed to ssh. Then the files are transfered and end up at the account of that user.
In the statement, it is clear stated that to exploit the flaw, some social engineering to the administrator with root access is needed. Fair deal, with that every file transfer protocol is vulnerable.
Be noted, in secured environments, the root account should not be able to do anything over ssh. That is to say, if the address is using the root account, access is denied.
Action to mitigate: Disallow root to enter over ssh. Or am I confused and is there still a vulnerability?
This is not going to be mitigated by disallowing the root login.
The CVE-2018-20685 and CVE-2019-6111 are not a CVEs where somebody could attack the server with SCP allowed but the malicious server can "break" the client, override some local files of unsuspected user who just wants to download some other file (indeed, it needs malicious/infected server).
The CVE-2020-15778 is about the way how the protocol is implemented and used that it is not a standard protocol, but depends on bash expansions of arguments that are passed to the server. Indeed, it requires some social engineering, but it can very successfully hide itself in a "harmless" SCP command to copy a file (by dropping backticks to the remote file list or something). While if you switch to well defined file transfer protocol (SFTP), you would need to hide much more, I guess probably the whole another ssh command, which is much easier to notice.
Again, for root it could cause much more harm, but generally, the users you use to login over the network also have some permissions on the server. They can have their public_html directory which can be used to upload malicious code to execute/download, they can have authorized_keys that can be modified by appending attacker public key, ... do not assume that disallowing root access will solve all the issues.
I think security scanners pick up on the openssh-server-NOT-GOOD-ENOUGH rpm.
Other than filing security exceptions, has anyone tried anything else?
I'm curious if anyone has already tried alternatives to OpenSSH on their servers (or crazy enough to try yum remove openssh-server)?