CVE-2022-34883: Security information for Hitachi Disk Array Systems(September 6, 2022):Vulnerability Information:Storage Solutions:Hitachi

• Vulnerability description
• Affected products
• Permanent action
• Interim action
• References
• Revision history

September 6, 2022
Hitachi, Ltd. IT Platform Products Management Division

Hitachi Disk Array Systems have the following vulnerability.

Security Information ID

Hitachi-sec-2022-307

Affected products

The following table shows the affected products.

Product Name

Hitachi RAID Manager SRA

Software Version

• Hitachi RAID Manager SRA: 02.01.04 *
• Hitachi RAID Manager SRA: 02.02.00 *
• Hitachi RAID Manager SRA: 02.03.01
• Hitachi RAID Manager SRA: 02.05.00 **

* Product end of support.
** Both SRA for Docker and Windows are affected.

• page top

Permanent action

1. Please perform <Procedure for deleting log files> action described in “Interim action”.
2. Please apply the countermeasure version. The countermeasure version is as follows.

• Hitachi RAID Manager SRA 02.03.02

• Hitachi RAID Manager SRA 02.05.01

• page top

Interim action

Workaround for vulnerability i):

- Do not use characters other than the usable characters described below for the following information registered in the “Add Array Manager” window of SRM.

<Registered information>
✔ IP address or host name of the RAID Manager server
✔ Username for connecting to the RAID Manager server using SSH
✔ Password for connecting to the RAID Manager server using SSH

<Usable characters>
One-byte alphanumeric characters and the following symbols
Hyphen (–), comma (,), period (.), colon (:), at mark (@), underscore (_), slash (/)

- The password might be already recorded in the SRM log files. Delete the log files by using the following procedure.
Notes:

• This procedure deletes the log file.
• If other problems occur on the SRM server, resolve them, and then perform the procedure.
• Do not perform any operation, such as registration or recovery, on SRM during the procedure.

<Procedure for deleting log files (for Docker RMSRA)>

1. Restart the SRM server.
2. Enable an SSH access to the SRM server. For the procedure, see the following web page:
   https://docs.vmware.com/en/Site-Recovery-Manager/8.5/com.vmware.srm.install_config.doc/GUID-DAB15876-4376-4D4B-A90A-1C54524685AE.html
3. Log in to the SRM server using SSH. (Use the admin user and the password you have set at the time of deployment.)
4. Run the su command to become a root user.
5. Run the following command to move to the log directory:
   cd /var/log/vmware/srm
6. Run the following command to check if the password is recorded in the archived log file:
   gunzip -c vmware-dr-.log.gz | grep " sh:" | wc -l
7. If the output result of Step 6 is 1 or greater, the password might be recorded. Delete the log file by running the following command:
   rm vmware-dr-.log.gz

<Procedure for deleting log files (for Windows RMSRA)>

1. Restart the SRM server.
2. Access the SRM server as a user with administrator privileges by using a remote desktop connection.
3. Open the explorer and move to the following directory:
   <SRM installation drive>:
   \ProgramData\VMware\VMware vCenter Site Recovery Manager\Logs
4. Copy the .gz archive log file to another directory.
   Name of the file to be copied:
   vmware-dr-.log.gz
5. Prepare a tool that decompresses the .gz archive log file that you copied in Step 4 and decompress the log file.
6. Run the following command at the command prompt and check if the password is recorded in the decompressed log file:
   find “operable program or batch file.” vmware-dr-.log
7. If an applicable part is output as a result of the command in Step 6, the password might be recorded. Delete the archived log file stored in the log directory.
   Log directory name:
   <SRM installation drive>:
   \ProgramData\VMware\VMware vCenter Site Recovery Manager\Logs
   File name:
   vmware-dr-.log.gz

<Procedure for deleting log (for both Docker/Windows RMSRA)>
If a log transfer setting and the like is configured on the SRM server, run the same check for transferred logs and delete logs as necessary.

Workaround for vulnerability ii):
Closely manage access rights to SRM.

• page top

• page top

Revision history

• September 6, 2022: This security information page is published.

• Hitachi, Ltd. (hereinafter referred to as “Hitachi”) tries to provide accurate information about security countermeasures. However, since information about security problems constantly changes, the contents of these Web pages are subject to change without prior notice. When referencing information, please confirm that you are referencing the latest information.

• The Web pages include information about products that are developed by non-Hitachi software developers. Vulnerability information about those products is based on the information provided or disclosed by those developers. Although Hitachi is careful about the accuracy and completeness of this information, the contents of the Web pages may change depending on the changes made by the developers.

• The Web pages are intended to provide vulnerability information only, and Hitachi shall not have any legal responsibility for the information contained in them. Hitachi shall not be liable for any consequences arising out of or in connection with the security countermeasures or other actions that you will take or have taken (or not taken) by yourself.

• The links to other web sites are valid at the time of the release of the page. Although Hitachi makes an effort to maintain the links, Hitachi cannot guarantee their permanent availability.

• VMware, VMware Site Recovery Manager, and VMware SRM are trademarks or registered trademarks of VMware, Inc. in the United States and other countries.

• Docker is a trademark or a registered trademark of Docker, Inc. in the United States and/or other countries. Docker, Inc. and other parties may also have trademark rights in other terms used herein.

• Microsoft, Windows are trademarks of the Microsoft group of companies.

• page top