scp in OpenSSH through 8.3p1 allows command injection in scp.c remote function, as demonstrated by backtick characters in the destination argument. NOTE: the vendor reportedly has stated that they intentionally omit validation of "anomalous argument transfers" because that could "stand a great chance of breaking existing workflows."
Created openssh tracking bugs for this issue:
Affects: fedora-all [bug 1860488]
Can be reproduce in 1 minute.
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 the place of scp for better security. More details about supported alternatives available at: https://access.redhat.com/articles/5284081
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.
This flaw has been rated as having moderate security impact because it is exploitable only when using scp client utility and the restriction bypass is limited only to cases when scp (copying of files) is allowed, but running remote commands or login to the remote server via ssh is not allowed.