CVE-2020-15778

A flaw was found in the scp program shipped with the openssh-clients package. An attacker having the ability to scp files to a remote server, could execute arbitrary commands on the remote server by including the command as a part of the filename being copied on the server. This command is run with the permissions of user with which the files were copied on the remote server. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability depending on the default system umask and selinux policy/enforcement.

This security flaw lies in the way scp command parses its command line arguments. The SSH protocol or any other applications shipped as a part of openssh-clients packages are not vulnerable.

In order to exploit this flaw, the attacker needs to social engineer or manipulate a system administrator (who has root access on the remote server) to run scp with a malicious command line parameter.

Administrators can uninstall openssh-clients for additional protection against accidental usage of this binary. Removing the openssh-clients package will make binaries like scp and ssh etc unavailable on that system. Also administrators can change the execute permissions on the scp binary. However this mitigation will be in place until the openssh-clients package is updated.

The loss of confidentiality, integrity and availability would depend on the system umask and selinux policies. For example, if the system umask is 000, one user CAN get access to another user's files and even execute them. However default umask for pretty much any modern unix system is 033, which gives a default permisson of 744. This does not cause any confidentiality problems that already does not exist outside of the scope of this bug. Also since the default permissions based on the umask would guard write and execute, there is no way to cause any loss of Integrity or Availability.

The CVSS score(s) listed for this vulnerability do not reflect the associated product's status, and are included for informational purposes to better understand the severity of this vulnerability.

As per upstream, because of the way scp is based on a historical protocol called rcp which relies on that style of argument passing and therefore encounters expansion problems. Making changes to how the scp command line works breaks the pattern used by scp consumers. Upstream therefore recommends the use of rsync in place of scp for better security.

Also, adding to the mitigation strategy the SCP protocol can be disabled by following the steps in the following documentation:

https://access.redhat.com/node/7053909

More details about supported alternatives available at: https://access.redhat.com/articles/5284081