RSA response to CVE-2020-15778 vulnerability with scp Command Injection in OpenSSH

[#1]

Article Number

000039893

Applies To

RSA Product Set: RSA SecurID
RSA Product/Service Type: Authentication Manager
RSA Version/Condition: 8.6.0, 8.5.x, 8.4, all 8.x
Platform: All
O/S Version: ESXi 5.0, Suse Linux 12.3, 12.x, 11.x
Product Name: Authentication Manager
Product Description: Appliance

Issue

Qualys is showing the following  S3 - OpenSSH Command Injection Vulnerability (Generic) 
First Detected: 11/09/2020 at 22:58:02 (GMT-0500)
Last Detected: 10/04/2021 at 21:41:25 (GMT-0500)
Times Detected: 53 Last Fixed: N/A QID: 105936
Category: Security Policy
CVE ID: CVE-2020-15778 Vendor Reference OpenSSH Bugtraq ID:
CVSS Base: 6.8 CVSS Temporal: 6.1 CVSS3 Base: 7.8 CVSS3 Temporal: 7.0

Note: Affected version checked till 8.6p1 as per PoC.
IMPACT: Successful exploitation could disclose sensitive information.  
SOLUTION: No solution available from Linux vendors yet.
Workaround: 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 Red Hat guide.
COMPLIANCE: Not Applicable
EXPLOITABILITY:     Qualys Reference: CVE-2020-15778 Description: Github Link: https://github.com/cpandya2909/CVE-2020-15778/ ASSOCIATED MALWARE: There is no malware information for this vulnerability.
RESULTS: Vulnerable version of OpenSSH Detected: OpenSSH_7.2p2, OpenSSL 1.0.2j-fips 26 Sep 2016

Cause

THREAT: OpenSSH is the premier connectivity tool for remote login with the SSH protocol. scp in OpenSSH through 8.6p1 allows command injection in the scp.c toremote function, as demonstrated by backtick characters in the destination argument. Affected Versions: 8.6p1 and prior versions of OpenSSH QID Detection Logic: The QID checks for the vulnerable versions of OpenSSH and checks the presence of scp command by executing 'which scp'

CVE ID: CVE-2020-15778 aka Qualys QID: 105936 vulnerability, according to NIST.
** DISPUTED ** scp in OpenSSH through 8.3p1 allows command injection in the scp.c toremote 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."
Published: July 24, 2020; 10:15:12 AM -0400
https://nvd.nist.gov/vuln/search/results?cves=on&cpe_version=cpe:/a:openbsd:openssh:6.6.1p1
 

Resolution

Response from the OpenSSH group:
 The scp command is a historical protocol (called rcp) which relies upon that style of argument passing and encounters expansion problems. It has proven very difficult to add "security" to the scp model. All attempts to "detect" and "prevent" anomalous argument transfers stand a great chance of breaking existing workflows. Yes, we recognize it the situation sucks. But we don't want to break the easy patterns people use scp for until there is a commonplace replacement. People should use rsync or something else instead if they are concerned.

RSA Response
This is again NOT associated with the SSH server running on AM appliances, but rather the client scp secure copy command which would be run by the appliance administrator from the command line.
This is a client bug, which you would have to invoke manually at the Linux command line running the scp client available from OpenSSH.  It does not really affect AM for 2 reasons;

1. A user has to login/SSH to Linux as unprivileged, and use scp to elevate their privilege or urn privileged commands.  No one logs into AM Linux except with the full privilege of rsaadmin.
2. SSH and console access to Linux is strictly controlled in the AM appliance.
3. There is no AM application that uses the scp command, a user would have to run it themself and inject something to elevate their privileges, which any user accessing AM Linux would already have.

 
OpenSSH is not going to fix this because of this limited exposure and fixing it could break some legitimate uses of scp.  See workaround for a way to pass the Qualys scan.

Workaround

OpenSSH is not going to fix this because of this limited exposure and fixing it could break some legitimate uses of scp. Qualys scan uses the ‘which’ command to find scp, so renaming /usr/bin/scp in AM Appliance Suse Linux will cause Qualys to not find this issue.

Image description

Notes

Background
CVE ID: CVE-2020-15778 aka Qualys QID: 105936 vulnerability, according to NIST.
** DISPUTED ** scp in OpenSSH through 8.3p1 allows command injection in the scp.c toremote 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."
Published: July 24, 2020; 10:15:12 AM -0400
https://nvd.nist.gov/vuln/search/results?cves=on&cpe_version=cpe:/a:openbsd:openssh:6.6.1p1