VMware Cloud Director 9.7, 10.0, 10.1, 10.2 and 10.3 Workaround for CVE-2022-22966
search cancel

VMware Cloud Director 9.7, 10.0, 10.1, 10.2 and 10.3 Workaround for CVE-2022-22966

book

Article ID: 320479

calendar_today

Updated On: 05-20-2022

Products

VMware Cloud Director

Issue/Introduction

VMware Cloud Director 10.1.4.1, 10.2.2.3 and 10.3.3 address a remote code execution vulnerability. The Common Vulnerabilities and Exposures project (https://cve.mitre.org) has assigned the identifier CVE-2022-22966 to this issue.

Note: For customers on 9.7 and 10.0 versions, if you cannot upgrade, please use the workaround below.

VMware released VMware Security Advisory VMSA-2022-0013 to help customers understand the issue and which upgrade path will fix it.

This article lists the recommended solution, upgrading to a patched release, but also provides a workaround for customers who can't upgrade.

Environment

VMware Cloud Director 9.x
VMware Cloud Director 10.x

Resolution

Permanent fixes have been released and are documented in VMware Security Advisory VMSA-2022-0013 .
Customers are strongly recommended to upgrade to one of these applicable versions immediately.
 
VMware Cloud Director VersionFixed VersionRelease Date
10.1.x10.1.4.1April 14th 2022
10.2.x10.2.2.3April 14th 2022
10.3.x10.3.3April 14th 2022


Workaround:
If upgrading to a recommended version is not an option, you may apply this workaround  for CVE-2022-22966 in 9.7, 10.0, 10.1, 10.2 and 10.3

Note:
  • If you have upgraded to a Fixed Version of Cloud Director, the script is not applicable. Running the script will result in false negatives stating that patching is required.
  • A new version of the script exists as of 20th May 2022 to address an additional issue specific to Console Proxy startup in versions 9.7.x and 10.0.x.
    • Both versions of the script fully protect against the security vulnerability.
    • If you have run the original script whilst on these releases, please re-run to apply the additional fixes.
    • If you are running versions other than 9.7.x and 10.0.x, there are no consequences to running the script again should you wish to validate.
      • For any validation, please ensure you also run the jConsole and jmxterm steps detailed below.
  • The script contains a self-extracting JRE upgrade in instances where an older version of JRE is being used.
  • Following the application of the workaround, any subsequent upgrade or patching of Cells to a build which is not a Fixed Version will revert the workaround.
    • Similarly, deploying Cells from a non-patched build will also result in the workaround not being applied. The script will need to be run on these newly deployed Cells.
    • In instances where a JRE rollback (detailed below) is required, you will also be in a position of not being fully patched. Please re-run the script to ensure your system is correctly patched. 
  • There is no functionality impact as a result of implementing this workaround

Perform the following steps:
  1. SSH to any Cell within the Server Group.
  2. Download the WA_CVE-2022-22966.sh script to the /tmp directory.
  3. Modify the permissions of the file to allow execution.
    1. chown root:vcloud /tmp/WA_CVE-2022-22966.sh 
    2. chmod 740 /tmp/WA_CVE-2022-22966.sh 
  4. Navigate to the /tmp directory of the Cell.
    1. cd /tmp
  5. Execute the script.
    1. ./WA_CVE-2022-22966.sh                                                                                                                                                                                 image.png                                       
  6. Ensure the services on the current Cloud Director Cell have restarted before proceeding with running the script on subsequent Cells.
    1. tail -f  /opt/vmware/vcloud-director/logs/cell.log
    2. You should see an entry like below when the Cell has completed startup. vcd_4.jpg          
  7. To verify the patch has correctly been applied, you can check the existing config and also the runtime settings of the Cloud Director Cell
    1. To check the Config, run the following command
      1. grep trustSerialData /opt/vmware/vcloud-director/bin/vmware-vcd-cell-common
      2. You should expect to see the following output
vcd_2.jpg
  1. To check the runtime settings, you can do so from any system that can connect to the Cells JMX port (8999) using either jConsole or jmxterm.
    1. To use jConsole, open the jConsole client and connect to the Cell
      1. Click on the MBeans tab in the top navigation bar
      2. Follow the navigation tree
        • java.lang
          • Runtime
            • Attributes
              • SystemProperties
      3. Double click javax.management.openmbean.TabularDataSupport
      4. Scroll until you find com.sun.jndi.ldap.object.trustSerialData
      5. The key, value pair must be present and the value must be false
    2. To use jmxterm, you will need to download it here
      1. Run the following command at the jmxterm command line, filling in the correct parameters
      2. echo "get --domain java.lang -b type=Runtime SystemProperties" | java -jar <path to jmxterm-1.0.2-uber.jar> -n -l <Cell FQDN>:8999 -u <administrator> -p '<administrator password>' | /bin/grep -A2 com.sun.jndi.ldap.object.trustSerialData
      3. Like with jConsole, you will get a key, value pair, and you should expect to see a false value.
  2. Running the script again post the 1st execution will report that the cell is "Protected"
 image.png
  1. SSH to the remaining Cells serially and repeat steps 3-5 until all Cells in the Server Group are patched.

JRE Rollback Steps
As mentioned above, there will be instances where the installed version of JRE needs to be upgraded as part of the patching steps.
In instances where this needs to be applied, should there be issues, please follow the rollback steps below.
  1. Move to the Cloud Director directory
    1. cd /opt/vmware/vcloud-director/
  2. Remove the existing JRE directory and files
    1. rm -rf jre
  3. Extract the pre-patch JRE directory and files
    1. tar xvfz /tmp/jre_backup.tar.gz 
  4. Start the Cloud Director Service
    1. service vmware-vcd restart
  5. Ensure the services on the current Cloud Director Cell have restarted before proceeding with running the script on subsequent Cells.
    1. tail -f  /opt/vmware/vcloud-director/logs/cell.log
    2. You should see an entry like below when the Cell has completed startup.
vcd_4.jpg


Additional Information

Checksum details for attached file - WA_CVE-2022-22966.sh
  • Previous Version
    • sha256sum
      • 797159c2c29c9919db8e671b2ec9587b5c11cea3f11542bdee94f90571ee83d2
    • sha512sum
      • d59054d03af2aa50afe55edfadeeb71032da209ebe38c75d6ca08ea821bd000111935fc9b79d6f8a2d828e6fce7fdd0dc29d14bbc93d42870db0b9f10e9b944d
  • Current Version
    • sha256sum
      • 01dd489312aea5f68e14cf75f77dcedfb15ac5bcb692ec33ab3bace678e23e31
    • sha512sum
      • 36fa692c9a9f67804dd777ee48d56f0f6584bcf9e0f039fab7380cd6e84b3eb49fe41e8efa30c79b93fea1f0938d96284cd2bd9b60a3a7f958506dd81fc12da8

For information on connecting to the Cloud Director Cells using jConsole, see
https://docs.vmware.com/en/VMware-Cloud-Director/9.7/com.vmware.vcloud.admin.doc/GUID-FA1FCDAD-AE4C-4D72-9B93-9FB764716AA9.html

Impact/Risks:
This workaround is applicable to affected versions of VMware Cloud Director 9.7, 10.0, 10.1, 10.2 and 10.3
Do not apply this workaround to other VMware products.
There is no functionality impact as a result of implementing this workaround

Note:
  • The WA_CVE-2022-22966.sh script will automatically restart the Cloud Director service when executed.
  • If issues are encountered with the automated restart of the vCloud Director service, you can do so manually by running the following command:
    • service vmware-vcd restart


Attachments

WA_CVE-2022-22966 get_app
Powered by Wolken Software