NSX-T Manager and Edge appliances are showing vulnerability to OpenSSH CVE-2023-51385 and CVE-2023-51767
search cancel

NSX-T Manager and Edge appliances are showing vulnerability to OpenSSH CVE-2023-51385 and CVE-2023-51767

book

Article ID: 371611

calendar_today

Updated On:

Products

VMware NSX

Issue/Introduction

Qualys tool identified NSX-T manager and edge are affected with OpenSSH multiple vulnerabilities.

CVEs Description:

- CVE-2023-51385
In ssh 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.

- CVE-2023-51767
OpenSSH through 9.6, when common types of DRAM are used, might allow row hammer attacks (for authentication bypass) because the integer value of authenticated in mm_answer_authpassword does not resist flips of a single bit. NOTE: this is applicable to a certain threat model of attacker-victim co-location in which the attacker has user privileges.

Environment

VMware NSX
VMware NSX-T Data Center

Cause

[1]
CVE-2023-51767 
Package : openssh

Analysis :

"The exploit for this vulnerability is super hard to implement (i.e., row hammer attack where the attacker tampers with the memory and compromises both stack and register variables). For the specific case of this vulnerability, the attacker must have the same privileges as the victim. Assuming that customers are not allowed to define new privileged local users on the operating system, we are not affected by the issue."  

By stating that the exploitation is "super hard to implement", we are trying to explain the nature of the possible exploit; not to provide a security measure. To exploit the vulnerability, a local attacker (who has the same privileges as the victim) should be able to analyze both stack and register variables associated with the ssh process in memory and to alter them which typically involves installing and running memory fingerprinting and analysis tools directly on the victim machine (NSX in this case) or the underlying infrastructure that the victim machine operates on. The other possible scenario is where an attacker-controlled VM is co-hosted with the NSX VM on a host with DIMMs susceptible to Rowhammer attack. 

If your security controls/policies allow such scenarios, then your NSX installation is vulnerable to the issue. To know more on the extent of the possible exploit, kindly refer to the following articles:
- Mayhem: Targeted Corruption of Register and Stack Variables
- Flip Feng Shui: Hammering a Needle in the Software Stack

[2] 
CVE-2023-51385
Package : openssh

Analysis :

To trigger this vulnerability, the following conditions shall be met: 

• Presence of shell metacharacters in the username or hostname 
• The use of ProxyCommand, LocalCommand or "match exec" that references the username or hostname. An example for this would be checking out repositories (Git) from untrusted sources (e.g., a Git submodule with shell characters in its username or hostname). The attack scenario is not applicable to NSX.
• Local users are not allowed to modify SSH client configuration on NSX 
• Untrusted hostnames or usernames are not used in SSH connections. Also note that, NSX is not a general-purpose operating system. It should not be used to checkout code from unknown/untrusted (Git) repositories."  

By stating that NSX is not a general-purpose operating system, we are trying to say that the client's operating environment should contain security policies and/or controls that neutralize the pre-conditions necessary to exploit the vulnerability. In this specific case, for example, a security control should restrict a local user from checking out code on NSX from an untrusted Git repository.

  1. An untrusted Git repository exists that includes a submodule that contains shell metacharacters in its username and/or hostname.
  2. The local NSX user installs Git command-line tool on NSX
  3. The local NSX user creates a custom SSH configuration; e.g., in the form of a .ssh_config file. As an example: 

    Host *.com
            ProxyCommand /usr/bin/nc -X connect -x 127.0.0.1:7890 %h %p

  4. The local NSX user uses Git command-line tool to checkout code from the untrusted Git repository

If your security controls/policies allow steps 2 to 4, then your NSX installation is vulnerable to the issue. Also, here is what OpenSSH's security advisory says about the issue:
Although we believe it is the user's responsibility to ensure validity of arguments passed to ssh(1), especially across a security boundary such as the git example above, OpenSSH 9.6 now bans most shell metacharacters from user and hostnames supplied via the command-line. This countermeasure is not guaranteed to be effective in all situations, as it is infeasible for ssh to universally filter shell metacharacters potentially relevant to user-supplied commands.

Resolution

For CVE-2023-51767, Ubuntu does not have a fix and marked this as deferred. Please refer this link from Ubuntu: https://ubuntu.com/security/CVE-2023-51767

For CVE-2023-51385, openssh version 1:8.2p1-4ubuntu0.11 has the fix. Please refer this link from Ubuntu : https://ubuntu.com/security/CVE-2023-51385 and https://changelogs.ubuntu.com/changelogs/pool/main/o/openssh/openssh_8.2p1-4ubuntu0.11/changelog (Fix publish by ubuntu on 02 Jan 2024)

NSX version where CVE-2023-51385 is fixed : NSX 3.2.4, 4.1.2.3, 4.1.2.4.

If the required security controls/policies are missing in the client's operating environment, no workarounds are available.