CERTsSecurity

Junos OS and Junos OS Evolved: CVSS (Max): 9.8

===========================================================================
AUSCERT External Security Bulletin Redistribution

ESB-2024.2935
2024-05 Reference Advisory: Junos OS and Junos OS Evolved: Multiple CVEs
reported in OpenSSH
10 May 2024

===========================================================================

AusCERT Security Bulletin Summary
———————————

Product: June OS
June OS Evolved
Publisher: Juniper Networks
Operating System: Juniper
Resolution: Patch/Upgrade
CVE Names: CVE-2016-10009

Original Bulletin:
https://supportportal.juniper.net/s/article/2024-05-Reference-Advisory-Junos-OS-and-Junos-OS-Evolved-Multiple-CVEs-reported-in-OpenSSH

Comment: CVSS (Max): 9.8 CVE-2024-1086 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)
CVSS Source: Juniper
Calculator: https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

– ————————–BEGIN INCLUDED TEXT——————–

Article IDJSA80837
Created2024-05-09
Last Updated2024-05-09
PrintReport a Security Vulnerability
Product AffectedThis advisory addresses: Junos OS versions greater than or
equal to 19.4R1 Junos OS Evolved versions greater than or equal to 22.3R1
SeverityNone
Severity Assessment (CVSS) Score9.8 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/
A:H)
Problem

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:

Impact
to
Fixed Junos OS
CVSS Impacted Open or
v3 OpenSSH SSH Junos OS
CVE Scores versions version Description Evolved Solution/Workaround
CVE- 5.3 < 7.6 7.6 The process_open function in sftp-server.c in Not In Junos OS/Junos OS Evolved the
2017-15906 OpenSSH before 7.6 does not properly prevent write Impacted sftpserver read-only mode is not
operations in readonly mode, which allows attackers supported at all.
to create zero-length files. Therefore, Junos OS/Junos OS
Evolved is not impacted and there
is no specific workaround needed.

CVE- 5.3 5.9 7.9 Remotely observable behavior in authgss2.c in Workaround In Junos OS/Junos OS Evolved, an attacker
2018-15919 – OpenSSH through 7.8 could be used by remote could use this flaw to make bruteforce
7.8 attackers to detect existence of users on a target guesses of account names and determine
system when GSS2 is in use. whether they exist or not on the server. No
further information is disclosed after, and
NOTE: the discoverer states ‘We understand that there is no availability or integrity
the OpenSSH developers do not want to treat such a impact.
username enumeration (or
“oracle”) as a vulnerability.’ Customers are recommended to apply the best
security practices to limit access to the
device only from trusted hosts and
administrators.
CVE- 5.3 <= 7.8 OpenSSH through 7.7 is prone to a user enumeration Not The affected/vulnerable components and the
2018-15473 7.7 vulnerability due to not delaying bailout for an Impacted corresponding code are not compiled into
invalid authenticating user until after the packet Junos OS/Junos OS Evolved SSH.
containing the request has been fully parsed,
related to auth2-gss.c, auth2hostbased.c, and As a result, the vulnerability is not
auth2-pubkey.c. applicable to customer systems.
CVE- 6.8 <= 8.0 Workaround The upstream recommendation from OpenSSH
2019-6109 7.9 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
An issue was discovered in OpenSSH 7.9. Due to the legacy RCP/SCP protocol. SCP protocol
missing character encoding in the progress can only be called using option “O”.
display, a malicious server (or Man-in-The-Middle
attacker) can employ crafted object names to As a workaround, customers are recommended
manipulate the client output, e.g., by using ANSI to use SFTP (Secure File Transfer Protocol).
control codes to hide additional files being SFTP is designed with better security
transferred. This affects refresh_progress_meter() mechanisms and is recommended by OpenSSH
in progressmeter.c. developers as a safer alternative.

CVE- 6.8 <= 8.0 In OpenSSH 7.9, due to accepting and displaying arbitrary stderr Workaround Customers are recommended to
2019-6110 7.9 output from the server, a malicious server (or Man-inTheMiddle follow the same workaround as
attacker) can manipulate the client output, for example to use mentioned for CVE2019-6109.
ANSI control codes to hide additional files being transferred.
CVE- 5.9 <= 8.0 An issue was discovered in OpenSSH 7.9. Due to the scp Workaround Customers are recommended to
2019-6111 7.9 implementation being derived from 1983 rcp, the server chooses follow the same workaround as
which files/directories are sent to the client. mentioned for CVE2019-6109.
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).

CVE- 5.3 <=7.9 8.0 In OpenSSH 7.9, scp.c in the scp client allows Workaround Customers are recommended to follow the
2018-20685 remote SSH servers to bypass intended access same workaround as mentioned for
restrictions via the filename of “.” or an empty CVE2019-6109.
filename. The impact is modifying the permissions
of the target directory on the client side.
CVE- 7.8 < 8.3 8.3 The scp in OpenSSH through 8.3p1 allows command Workaround In order to perform a command injection,
2020-15778 injection in the scp.c toremote function, as an attacker would have to craft a file,
demonstrated by backtick characters in the that when copied with SCP in a
destination argument. configuration, causes “utimes” to fail.

NOTE: the vendor reportedly has stated that they The CVE is disputed by the OpenSSH
intentionally omit validation of developers.
“anomalous argument transfers” because that could
“stand a great chance of breaking existing Customers are recommended to follow the
workflows.” same workaround as mentioned for
CVE2019-6109.
CVE- 5.9 5.7-8.6 8.7 Workaround This vulnerability is specific to the
2020-14145 manual initial connection attempts from
The client side in OpenSSH 5.7 through 8.4 has an the client side. These types of issues
Observable Discrepancy leading to an information can be mitigated by using
leak in the algorithm negotiation. This allows certificate-based connections.
man-in-the-middle attackers to target initial
connection attempts (where no host key for the Customers are recommended to use the
server has been cached by the client). “ssh host-certificate-file” config
option from CLI to configure
NOTE: some reports state that 8.5 and 8.6 are also certificate-based hostkey algorithms.
affected.
The CVE is disputed by the OpenSSH
developers.

CVE- 7.5 8.2 8.3 The scp client in OpenSSH 8.2 incorrectly sends Workaround This attack can achieve no more than what a
2020-12062 duplicate responses to the server upon a utimes hostile peer is already capable of within
system call failure, which allows a malicious the SCP protocol. Therefore, while the
unprivileged user on the remote server to overwrite vulnerability exists, its impact is limited
arbitrary files in the client’s download directory and does not pose a significant risk beyond
by creating a crafted subdirectory anywhere on the what is already possible within SCP’s
remote server. functionality.
The victim must use the command scp -rp to download
a file hierarchy containing, anywhere inside, this Recommended to follow the same workaround
crafted subdirectory. as mentioned for CVE20196109.

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.
CVE- 7.0 6.2 8.8 Workaround Neither AuthorizedKeysCommand nor
2021-41617 – AuthorizedPrincipalsCommand are enabled by
8.7 default. Customers can workaround the issue
by not configuring
The sshd in OpenSSH 6.2 through 8.x before 8.8, “authorized-keys-command” or
when certain non-default configurations are used, “authorized-principals” under [ system
allows privilege escalation because supplemental services ssh ] hierarchy.
groups are not initialized as expected. Helper
programs for AuthorizedKeysCommand Even if customers enable the feature, they
and AuthorizedPrincipalsCommand may run with must provide a script or program that is
privileges associated with group memberships of the already wholly trusted. Customers should
sshd process, if the configuration specifies only specify a trusted program for either
running the command as a different user. of these options.

CVE- 7.1 8.2 8.5 The “ssh-agent” in OpenSSH before 8.5 has a double Not The “ssh-agent” is not accessible via Junos OS/
2021-28041 – free that may be relevant in a few less common Impacted Junos OS Evolved CLI. For users with shell
8.4 scenarios, such as unconstrained agent-socket access this issue is exploitable when using
access on a legacy operating system, or the “ssh-agent” to forward an agent to an account
forwarding of an agent to an attacker-controlled shared with a malicious user or to a host where
host. 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- 5.3 <= 8.8 OpenSSH through 8.7 allows remote attackers, who Not As per the CVE Details https://nvd.nist.gov/vuln
20012 8.7 have a suspicion that a certain combination of Impacted /detail/CVE2016-20012:
username and public key is known to an SSH server, “The vendor (OpenSSH) does not recognize user
to test whether this suspicion is correct. This enumeration as a vulnerability for this
occurs because a challenge is sent only when that product.”
combination could be valid for a login session.

NOTE: the vendor does not recognize user
enumeration as a vulnerability for this product.

CVE- 3.7 <= 8.9 An issue was discovered in OpenSSH before Not This CVE is not considered applicable to
2021- 8.8 8.9. If a client is using public-key Impacted Junos OS/Junos OS Evolved because FIDO
36368 authentication with agent forwarding but without authentication is not support by the SSH
-oLogLevel=verbose, and an attacker has silently client in either OS.
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.
CVE- 9.8 < 9.3p2 The PKCS#11 feature in ssh-agent in OpenSSH before Workaround Junos OS/Junos OS Evolved CLI do not
2023-38408 9.3p2 9.3p2 has an insufficiently trustworthy search provide any SSH command to configure an
path, leading to remote code execution if an agent option to allow agent forwarding.
is forwarded to an attacker-controlled system.
(Code in /usr/lib is not necessarily safe for The only way a user could be exposed to
loading into sshagent.) NOTE: this issue exists this vulnerability is by manually
because of an incomplete fix for CVE-2016-10009. 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- 9.8 8.9 9.3 The “ssh-add” in OpenSSH before 9.3 adds smartcard keys to Not As Junos OS/Junos OS Evolved is
2023- – ssh-agent without the intended per-hop destination constraints. Impacted using a OpenSSH version 7.5p1 which
28531 9.2 The earliest affected version is 8.9. is prior to the earliest affected
version (8.9)

Hence, Junos OS/Junos OS Evolved is
not impacted by the CVE.
CVE- 5.9 <= 9.6 The SSH transport protocol with certain OpenSSH extensions, Workaround Junos OS/Junos OS Evolved can only
2023- 9.5 found in OpenSSH before 9.6 and other products, allows remote be impacted when the ssh cipher list
48795 attackers to bypass integrity checks such that some packets are includes chacha20-poly135.
omitted (from the extension negotiation message), and a client
and server may consequently end up with a connection for which Furthermore, in Junos OS/Junos OS
some security features have been downgraded or disabled, aka a Evolved, chacha20-poly1305 has been
Terrapin attack. This occurs because the SSH Binary Packet hidden and deprecated as a default
Protocol (BPP), implemented by these extensions, mishandles the algorithm for sshd:
handshake phase and mishandles use of sequence numbers. 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- 5.5 < 9.6 In ssh-agent in OpenSSH before 9.6, certain destination Not This does not impact Junos OS/Junos OS
2023- 9.6 constraints can be incompletely applied. When destination Impacted Evolved because it does not support the
51384 constraints are specified during addition of PKCS#11hosted use of “ssh-agent” with destination
private keys, these constraints are only applied to the first constraints.
key, even if a
PKCS#11 token returns multiple keys.
CVE- 6.5 < 9.6 Not Junos OS/Junos OS Evolved are not
2023- 9.6 Impacted impacted because the CLI does not
51385 In ssh (SSH client program) in OpenSSH before 9.6, OS command expose the ProxyCommand option.
injection might occur if a user name or host name has shell
metacharacters, and this name is referenced by an expansion Customers are recommended not to (1)
token in certain situations. For example, an untrusted Git configure any SSH options using shell
repository can have a submodule with shell metacharacters in a or (2) connect to any untrusted SSH
user name or host name. hosts.

Solution Refer to the table above to assess impact.WorkaroundRefer to the table
above for applicable workarounds. Modification History

2024-05-09: Initial Publication

Related Information

o KB16613: Overview of the Juniper Networks SIRT Quarterly Security Bulletin
Publication Process
o KB16765: In which releases are vulnerabilities fixed?
o KB16446: Common Vulnerability Scoring System (CVSS) and Juniper’s Security
Advisories
o Report a Security Vulnerability – How to Contact the Juniper Networks
Security Incident Response Team
o CVE Mitre: https://cve.mitre.org/
o SUSE: https://www.suse.com/security/cve/.html
o OpenSSH Release Notes: https://www.openssh.com/releasenotes.html
o National Vulnerability Database: https://nvd.nist.gov/vuln
o SSH-MITM: https://docs.ssh-mitm.at/vulnerabilities
o OpenSSH Portable: https://github.com/openssh/openssh-portable

– ————————–END INCLUDED TEXT———————-

You have received this e-mail bulletin as a result of your organisation’s
registration with AusCERT. The mailing list you are subscribed to is
maintained within your organisation, so if you do not wish to continue
receiving these bulletins you should contact your local IT manager. If
you do not know who that is, please send an email to auscert@auscert.org.au
and we will forward your request to the appropriate person.

NOTE: Third Party Rights
This security bulletin is provided as a service to AusCERT’s members. As
AusCERT did not write the document quoted above, AusCERT has had no control
over its content. The decision to follow or act on information or advice
contained in this security bulletin is the responsibility of each user or
organisation, and should be considered in accordance with your organisation’s
site policies and procedures. AusCERT takes no responsibility for consequences
which may arise from following or acting on information or advice contained in
this security bulletin.

NOTE: This is only the original release of the security bulletin. It may
not be updated when updates to the original are made. If downloading at
a later date, it is recommended that the bulletin is retrieved directly
from the author’s website to ensure that the information is still current.

Contact information for the authors of the original document is included
in the Security Bulletin above. If you have any questions or need further
information, please contact them directly.

Previous advisories and external security bulletins can be retrieved from:

https://www.auscert.org.au/bulletins/

===========================================================================
Australian Computer Emergency Response Team
The University of Queensland
Brisbane
Qld 4072

Internet Email: auscert@auscert.org.au
Facsimile: (07) 3365 7031
Telephone: (07) 3365 4417 (International: +61 7 3365 4417)
AusCERT personnel answer during Queensland business hours
which are GMT+10:00 (AEST).
On call after hours for member emergencies only.
===========================================================================Security BulletinsRead More