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." Reference: https://www.openssh.com/security.html
Created openssh tracking bugs for this issue: Affects: fedora-all [bug 1860488]
Reproducer: https://github.com/cpandya2909/CVE-2020-15778 Can be reproduce in 1 minute.
External References: https://access.redhat.com/articles/5284081 https://github.com/cpandya2909/CVE-2020-15778
Mitigation: 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
Statement: 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 bug is now closed. Further updates for individual products will be reflected on the CVE page(s): https://access.redhat.com/security/cve/cve-2020-15778