Knowledge BaseBack

2024-05 Reference Advisory: Junos OS and Junos OS Evolved: Multiple CVEs reported in OpenSSH

JSA80837
2024-05-09
2024-05-09
This advisory addresses: Junos OS versions greater than or equal to 19.4R1 Junos OS Evolved versions greater than or equal to 22.3R1
None
9.8 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)

This Juniper Security Advisory (JSA) presents an analysis of CVEs known to affect OpenSSH v7.5p1.

Junos OS and Junos OS Evolved use OpenSSH v7.5p1 that has been heavily customized. As a result, some scanners may misidentify known vulnerabilities in OpenSSH v7.5p1 to be present in Junos OS and Junos OS Evolved. 

It's important to note that most of these CVEs do not impact Junos OS or Junos OS Evolved, and for those that do have an impact, clear workarounds have been prescribed below.

Multiple OpenSSH CVEs have been reported since v7.5p1 and their analysis is mentioned below: 

CVE CVSS v3
Scores		Impacted
OpenSSH versions 		Fixed Open
SSH
version		DescriptionImpact to
Junos OS or
Junos OS Evolved 		Solution/Workaround
CVE-
2017-15906 		5.3< 7.67.6 The process_open function in sftp-server.c in OpenSSH before 7.6 does not properly prevent write operations in readonly mode, which allows attackers to create zero-length files. Not ImpactedIn Junos OS/Junos OS Evolved the sftpserver read-only mode is not supported at all.   
Therefore, Junos OS/Junos OS Evolved is not impacted and there is no specific workaround needed.
CVE-
2018-15919 		5.35.9 - 7.87.9Remotely observable behavior in authgss2.c in OpenSSH through 7.8 could be used by remote attackers to detect existence of users on a target system when GSS2 is in use. 
 
NOTE: the discoverer states 'We understand that the OpenSSH developers do not want to treat such a username enumeration (or
"oracle") as a vulnerability.' 		WorkaroundIn Junos OS/Junos OS Evolved, an attacker could use this flaw to make bruteforce guesses of account names and determine whether they exist or not on the server. No further information is disclosed after, and there is no availability or integrity impact.  
 
Customers are recommended to apply the best security practices to limit access to the
device only from trusted hosts and administrators.
CVE-
2018-15473 		5.3 <= 7.77.8OpenSSH through 7.7 is prone to a user enumeration vulnerability due to not delaying bailout for an invalid authenticating user until after the packet containing the request has been fully parsed, related to auth2-gss.c, auth2hostbased.c, and auth2-pubkey.c. Not ImpactedThe affected/vulnerable components and the corresponding code are not compiled into Junos OS/Junos OS Evolved SSH. 
 
As a result, the vulnerability is not applicable to customer systems. 
CVE-
2019-6109 		6.8<= 7.9 8.0An issue was discovered in OpenSSH 7.9. Due to missing character encoding in the progress display, a malicious server (or Man-in-The-Middle attacker) can employ crafted object names to manipulate the client output, e.g., by using ANSI control codes to hide additional files being transferred. This affects refresh_progress_meter() in progressmeter.c. WorkaroundThe upstream recommendation from OpenSSH developers is not to use SCP with untrusted servers due to these vulnerabilities. 
 
Furthermore, starting from OpenSSH v9.0
SCP uses SFTP protocol by default instead of the legacy RCP/SCP protocol. SCP protocol can only be called using option “O”.
 
As a workaround, customers are recommended to use SFTP (Secure File Transfer Protocol). SFTP is designed with better security mechanisms and is recommended by OpenSSH developers as a safer alternative. 
CVE-
2019-6110 		6.8 <= 7.98.0 In OpenSSH 7.9, due to accepting and displaying arbitrary stderr output from the server, a malicious server (or Man-inTheMiddle attacker) can manipulate the client output, for example to use ANSI control codes to hide additional files being transferred. WorkaroundCustomers are recommended to follow the same workaround as mentioned for CVE2019-6109. 
CVE-
2019-6111 		5.9<= 7.98.0 An issue was discovered in OpenSSH 7.9. Due to the scp implementation being derived from 1983 rcp, the server chooses which files/directories are sent to the client.
However, the scp client only performs cursory validation of the object name returned (only directory traversal attacks are prevented). A malicious scp server (or Manin-The-Middle attacker) can overwrite arbitrary files in the scp client target directory. If recursive operation (-r) is performed, the server can manipulate subdirectories as well (for example, to overwrite the .ssh/authorized_keys file). 		WorkaroundCustomers are recommended to follow the same workaround as mentioned for CVE2019-6109. 
CVE-
2018-20685		5.3<=7.98.0 In OpenSSH 7.9, scp.c in the scp client allows remote SSH servers to bypass intended access restrictions via the filename of “.” or an empty filename. The impact is modifying the permissions of the target directory on the client side.  WorkaroundCustomers are recommended to follow the same workaround as mentioned for CVE2019-6109. 
CVE-
2020-15778		7.8< 8.38.3 The 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." 		Workaround
 		In order to perform a command injection, an attacker would have to craft a file, that when copied with SCP in a configuration, causes “utimes” to fail. 
 
The CVE is disputed by the OpenSSH developers.
 
Customers are recommended to follow the same workaround as mentioned for CVE2019-6109.
CVE-
2020-14145 		5.95.7-8.68.7 The client side in OpenSSH 5.7 through 8.4 has an Observable Discrepancy leading to an information leak in the algorithm negotiation. This allows man-in-the-middle attackers to target initial connection attempts (where no host key for the server has been cached by the client). 

NOTE: some reports state that 8.5 and 8.6 are also affected. 
 
 		WorkaroundThis vulnerability is specific to the manual initial connection attempts from the client side. These types of issues can be mitigated by using certificate-based connections.
 
Customers are recommended to use the
“ssh host-certificate-file” config option from CLI to configure certificate-based hostkey algorithms.
 
The CVE is disputed by the OpenSSH developers.
CVE-
2020-12062		7.58.28.3 The scp client in OpenSSH 8.2 incorrectly sends duplicate responses to the server upon a utimes system call failure, which allows a malicious unprivileged user on the remote server to overwrite arbitrary files in the client's download directory by creating a crafted subdirectory anywhere on the remote server. 
The victim must use the command scp -rp to download a file hierarchy containing, anywhere inside, this crafted subdirectory.  
 
NOTE: the vendor points out that "this attack can achieve no more than a hostile peer is already able to achieve within the scp protocol" and "utimes does not fail under normal circumstances.		WorkaroundThis attack can achieve no more than what a hostile peer is already capable of within the SCP protocol. Therefore, while the vulnerability exists, its impact is limited and does not pose a significant risk beyond what is already possible within SCP's functionality.
 
Recommended to follow the same workaround as mentioned for CVE20196109.
CVE-
2021-41617 		7.0 6.2 - 8.78.8 The sshd in OpenSSH 6.2 through 8.x before 8.8, when certain non-default configurations are used, allows privilege escalation because supplemental groups are not initialized as expected. Helper programs for AuthorizedKeysCommand and AuthorizedPrincipalsCommand may run with privileges associated with group memberships of the sshd process, if the configuration specifies running the command as a different user. WorkaroundNeither AuthorizedKeysCommand nor AuthorizedPrincipalsCommand are enabled by default. Customers can workaround the issue by not configuring
“authorized-keys-command” or “authorized-principals” under [ system services ssh ]  hierarchy.
 
Even if customers enable the feature, they must provide a script or program that is already wholly trusted. Customers should only specify a trusted program for either of these options.
CVE-
2021-28041		7.18.2 - 8.48.5 The “ssh-agent” in OpenSSH before 8.5 has a double free that may be relevant in a few less common scenarios, such as unconstrained agent-socket access on a legacy operating system, or the forwarding of an agent to an attacker-controlled host. Not ImpactedThe “ssh-agent” is not accessible via Junos OS/Junos OS Evolved CLI. For users with shell access this issue is exploitable when using “ssh-agent” to forward an agent to an account shared with a malicious user or to a host where the attacker has the root access.
 
Customers can avoid the issue by never initiating an SSH connection with sshagent forwarding (-A option) to untrusted SSH servers from a Unix shell. Customers should not SSH into untrusted SSH servers anyway.
CVE- 2016- 20012 5.3<= 8.78.8 OpenSSH through 8.7 allows remote attackers, who have a suspicion that a certain combination of username and public key is known to an SSH server, to test whether this suspicion is correct. This occurs because a challenge is sent only when that combination could be valid for a login session.

NOTE: the vendor does not recognize user enumeration as a vulnerability for this product. 		Not Impacted
 
 		As per the CVE Details https://nvd.nist.gov/vuln/detail/CVE2016-20012:  
“The vendor (OpenSSH) does not recognize user enumeration as a vulnerability for this product.”
CVE-
2021- 36368		3.7<= 8.88.9 An issue was discovered in OpenSSH before
8.9. If a client is using public-key authentication with agent forwarding but without -oLogLevel=verbose, and an attacker has silently modified the server to support the None authentication option, then the user cannot determine whether FIDO (Fast Identity Online) authentication is going to confirm that the user wishes to connect to that server, or that the user wishes to allow that server to connect to a different server on the user's behalf. NOTE: the vendor's position is "this is not an authentication bypass, since nothing is being bypassed. 		Not Impacted
 		This CVE is not considered applicable to
Junos OS/Junos OS Evolved because FIDO authentication is not support by the SSH client in either OS.
CVE-
2023-38408		9.8 < 9.3p29.3p2 The PKCS#11 feature in ssh-agent in OpenSSH before 9.3p2 has an insufficiently trustworthy search path, leading to remote code execution if an agent is forwarded to an attacker-controlled system. (Code in /usr/lib is not necessarily safe for loading into sshagent.) NOTE: this issue exists because of an incomplete fix for CVE-2016-10009.Workaround
 		Junos OS/Junos OS Evolved CLI do not provide any SSH command to configure an option to allow agent forwarding. 
 
The only way a user could be exposed to this vulnerability is by manually dropping to a Unix shell and connecting to a malicious host with agent-forwarding enabled in their session. Customers are recommended to avoid initiating an SSH connection enabling agent forwarding using “-A” option from the shell.
CVE-
2023- 28531 		9.88.9 - 9.29.3 The “ssh-add” in OpenSSH before 9.3 adds smartcard keys to ssh-agent without the intended per-hop destination constraints. The earliest affected version is 8.9. Not Impacted
 		As Junos OS/Junos OS Evolved is using a OpenSSH version 7.5p1 which is prior to the earliest affected version (8.9)
 
Hence, Junos OS/Junos OS Evolved is not impacted by the CVE. 
CVE-
2023- 48795 		5.9<= 9.59.6 The SSH transport protocol with certain OpenSSH extensions, found in OpenSSH before 9.6 and other products, allows remote attackers to bypass integrity checks such that some packets are omitted (from the extension negotiation message), and a client and server may consequently end up with a connection for which some security features have been downgraded or disabled, aka a Terrapin attack. This occurs because the SSH Binary Packet Protocol (BPP), implemented by these extensions, mishandles the handshake phase and mishandles use of sequence numbers.WorkaroundJunos OS/Junos OS Evolved can only be impacted when the ssh cipher list includes chacha20-poly135. 
 
Furthermore, in Junos OS/Junos OS Evolved, chacha20-poly1305 has been hidden and deprecated as a default algorithm for sshd: 
Junos OS: 19.4R3-S13, 20.4R3-S10,
21.4R3-S6, 22.1R3-S5, 22.2R3-S3,
22.4R3-S1, 23.2R2, 23.4R2, 24.1R1, and all subsequent releases. 
Junos OS Evolved: 19.4R3-S13, 20.4R3S10, 21.4R3-S6, 22.1R3-S5, 22.2R3-S3, 22.4R3-S1, 23.2R2, 23.4R2, 24.1R1, and all subsequent releases.
 
Customers are recommended to either use one of the fixed releases mentioned above or not to use the ssh cipher option chacha20-poly135 at all.
 
For example, the following config is recommended best practice:
set system services ssh ciphers [aes128gcm@openssh.com aes256gcm@openssh.com]
 
You can find more information about this workaround in Juniper's knowledge base article JSA76462:
https://kb.juniper.net/JSA76462  
CVE-
2023- 51384 		5.5 < 9.69.6 In ssh-agent in OpenSSH before 9.6, certain destination constraints can be incompletely applied. When destination constraints are specified during addition of PKCS#11hosted private keys, these constraints are only applied to the first key, even if a
PKCS#11 token returns multiple keys. 		Not ImpactedThis does not impact Junos OS/Junos OS Evolved because it does not support the use of "ssh-agent" with destination constraints.
CVE-
2023- 51385 		6.5 < 9.69.6 In ssh (SSH client program) in OpenSSH before 9.6, OS command injection might occur if a user name or host name has shell metacharacters, and this name is referenced by an expansion token in certain situations. For example, an untrusted Git repository can have a submodule with shell metacharacters in a user name or host name. Not ImpactedJunos OS/Junos OS Evolved are not impacted because the CLI does not expose the ProxyCommand option. 
 
Customers are recommended not to (1) configure any SSH options using shell or (2) connect to any untrusted SSH hosts.

 

 Refer to the table above to assess impact.Refer to the table above for applicable workarounds. 
2024-05-09: Initial Publication