Browsed by
Tag: security

VMSA-2022-0033 Critical VMware Security Advisory

VMSA-2022-0033 Critical VMware Security Advisory

On 13 December 2022 VMware released a security advisory for VMware ESXi, Workstation, and Fusion.

The VMSA carries a rating of Moderate with a CVSSv3 score of 5.9 for VMware ESXi 8.0 and 7.0

It carries a rating of Critical with a CVSSv3 score of 9.3 for Fusion 12.x and Workstation 16.x

Fusion 13.x and Workstation 17.x are Unaffected.

Upgrade ESXi 8.x to ESXi 8.0a Build 20842819 (or later)

Upgrade ESXi 7.x to 7.0U3i Build 20842708 (or later)

Upgrade Fusion to 12.2.5, or 13.x. Similarly, upgrade Workstation to 16.2.5, or 17.x

More details: https://www.vmware.com/security/advisories/VMSA-2022-0033.html

Pro Tip: Be sure to sign up for VMware Security Advisory emails by clicking the signup link on the VMSA page. This way you can be notified immediately when a new VMSA is released.

VMSA-2022-0027 – Critical VMware Security Advisory

VMSA-2022-0027 – Critical VMware Security Advisory

On October 25 2022, VMware released VMware Security Advisory VMSA-2022-0027 affecting VMware Cloud Foundation 3.x.

Resources:

VMSA-2021-0027: https://www.vmware.com/security/advisories/VMSA-2022-0027.html

The affected products do NOT include VCF 4.x, only versions earlier than 3.11. Most of these products are EOGS (End of General Support) and should be removed from production.

VMSA-2021-0028: Critical VMware Security Advisory (Multiple Products; Apache Log4j Vulnerability)

VMSA-2021-0028: Critical VMware Security Advisory (Multiple Products; Apache Log4j Vulnerability)

On Friday, December 10, 2021, VMware released VMware Security Advisory VMSA-2021-0028 affecting numerous VMware products including vCenter Server. This advisory is re: Apache Log4j vulnerability CVE-2021-44228 with a CVSSv3 score of 10 out of 10.

Resources:

VMSA-2021-0028: https://www.vmware.com/security/advisories/VMSA-2021-0028.html
FAQ: https://via.vmw.com/vmsa-2021-0028-faq
Unaffected VMware products can be referred to on the Knowledge Base article: https://kb.vmware.com/s/article/87068
VMware Blog “Investigating the Log4j Vulnerability”: https://blogs.vmware.com/security/2021/12/investigating-cve-2021-44228-log4shell-vulnerability.html

The key takeaway is that IMMEDIATE ACTION IS REQUIRED. Workaround should be applied to all running products immediately.

This is being actively exploited in the wild, and should be treated as an emergency change with highest priority.

This vulnerability is in the open-source Apache Log4j Java logging library, which is used in numerous software packages. This is not a VMware-specific issue.

Additional background information:
Tech Solvency Log4Shell log4j vulnerability (CVE-2021-44228) – cheat-sheet reference guide

VMSA-2021-0020: Critical vCenter Server Security Advisory

VMSA-2021-0020: Critical vCenter Server Security Advisory

On Tuesday, September 21, 2021, VMware released VMware Security Advisory VMSA-2021-0020 affecting vCenter Server. This VMSA contains 1 Critical advisory and 18 Important advisories.

Resources:

VMSA-2021-0020: https://www.vmware.com/security/advisories/VMSA-2021-0020.html
Workaround*: VMware KB 85717: https://kb.vmware.com/kb/85717
FAQ: https://via.vmw.com/vmsa-2021-0020-faq
VMware Blog “VMSA-2021-0020: What You Need to Know”: https://via.vmw.com/vmsa-2021-0020-blog
VMware Communities: https://via.vmw.com/vmsa-2021-0020-community

*Workaround provided only for 1 Critical vulnerability. Additional 18 lower vulnerabilities require patch to be applied. Workaround should only be used as a temporary measure until patching can be completed. Refer to FAQ for additional information.

The key information to share is that IMMEDIATE ACTION IS REQUIRED. Apply the vCenter patch version now, or apply the workaround (and understand the impact to functionality) if you cannot patch immediately.

VMware has released a very detailed blog and FAQ for this VMSA, which should help clarify questions that are sure to arise. These resources are linked above.

Updated vSphere Security Configuration Guides

Updated vSphere Security Configuration Guides

As a follow-up to the previous post, VMware Security expert Bob Plankers has just published an update to the vSphere Security Configuration guides. The changes are detailed in a blog article here: 

https://blogs.vmware.com/vsphere/2021/02/evolving-the-vmware-vsphere-security-configuration-guides.html

One specific item of interest around OpenSLP/CIM service (ref. VMSA-2019-0022, VMSA-2020-0023):

“Added and updated guidance for disabling SLP and CIM service daemons on ESXi. Security advisories are often good opportunities to assess the state of things, and most customers do not use these protocols. No VMware products use these protocols, either. We now have good methods and guidance for disabling them.”

Furthermore, while not detailed in the blog, I understand that slpd service is disabled by default in ESXi going forward.

You can download the vSphere Security Configuration guides at https://core.vmware.com/security-configuration-guide

Intel L1 Terminal Fault Security Vulnerability

Intel L1 Terminal Fault Security Vulnerability

The following resources should be helpful in understanding the Intel L1 Terminal Fault vulnerability announced today.

VMware KB 55636:  VMware Overview of ‘L1 Terminal Fault’ (L1TF) Speculative-Execution vulnerabilities in Intel processors: CVE-2018-3646, CVE-2018-3620, and CVE-2018-3615 (55636)

Patching for CVE-2018-3646 “L1TF – VMM” could have performance impacts in customer virtualization environments.  Refer to VMware KB 55806 for further details.

Overview video from Intel:

More detailed video from RedHat:

vRealize Operations Certificate Installation Error

vRealize Operations Certificate Installation Error

There is a good bit of information available for installing certificates for vROps 6.x. I encountered an issue that required a VMware Support case and uncovered some changes in vRealize Operations Manager 6.3 and 6.4.

My environment was using an internally signed SHA1 (128-bit) certificate. This was being updated to a 256-bit certificate.

The process to generate a certificate for vROps is more complex than typical, and is poorly documented by VMware. There are some articles with better information on how to create and install vROps certificates:
http://www.kanap.net/2015/02/install-a-custom-certificate-for-vrealize-operations-manager/
http://virtuallyeuc.com/vrealize-operations-manager-6-0-certificate-creation/

After carefully following the process to create the CSR, having the certificate signed, and building the .pem file, vROps refused to accept the new cert:

Operation failed. If the error persists, contact VMware support.

Review casa.log [/var/log/casa_logs/casa.log on your master vROps node] and look for something similar to:

2016-12-06 17:45:44,102 [x2000UIE] [ajp-nio-127.0.0.1-8011-exec-7] INFO support.subprocess.GeneralCommand:255 - Command '/usr/lib/vmware-vcopssuite/python/bin/python /usr/lib/vmware-casa/bin/vropsCertificateTool.py -i /storage/db/tmp/uploaded_cert.tmp --no_describe --json --level NONE' threw exception: CommandLineExitException: key=general.failure; args=1,; cause=
2016-12-06 17:45:44,103 [x2000UIE] [ajp-nio-127.0.0.1-8011-exec-7] INFO casa.security.SecurityService:946 - validateCertificateFile script's STDOUT:
{"errors": [], "exitCode": 0, "warnings": [{"warning_args": "/C=US/ST=State/L=City/O=Org/OU=Domain/CN=CA", "warning_code": "WARN-2", "warning_message": "Issuer and subject names match (/C=US/ST=State/L=City/O=Org/OU=Domain/CN=CA), but the issuer key does not. This is likely the wrong issuer certificate."}]}

So here’s what happened:
Starting in vROps 6.3, a change was made to how vROps handles the upload of a certificate.  The service used for the handling of the chain file has a file limit of 8192 bytes.
– My certificate chain (.pem file) was 10.7 KB, due to the fact that we have 2 intermediate certificates (Root Cert->Intermediate 1->Intermediate 2->Server Cert)
– vROps was essentially truncating the file, causing it to interpret the first intermediate certificate as the root, causing the “likely the wrong issuer certificate” error.
– I confirmed the issue exists on 6.3 and 6.4; the TSE was not able to replicate on 6.2.1
The vRealize Operations Manager supports custom security certificates with key length up to 8192 bits. An error is displayed when you try to upload a security certificate generated with a stronger key length beyond 8192 bits.

Solutions:
1) Use a certificate with only one intermediate, which results in a .pem file size of ~7 KB
– I had the option to request a GlobalSign certificate at minimal cost; we were in the process of requesting this anyway to rule out our internal CA as the problem. It is of course understood that this will not be an option for many users.
2) “The workaround is to edit the ‘maxInMemorySize’ value for the spring service which handles the upload of the cert. This should prevent the use of the temp file which in turn will bypass the part of the code that reads the temp file with the 10k limit.” – Provided by VMware TSE. I did not pursue this workaround as we already had the new GlobalSign certificate ready to test on the same day this workaround was proposed. I have asked for additional information on this workaround and will update if it is provided.

Hopefully this information helps diagnose failures in certificate installation in vRealize Operations 6.3 or 6.4. I’m not sure why 8 KB was the file size limit chosen, but it is too small for many environments with multiple intermediate CAs. Hopefully this will be resolved in the next release.

Update:
1) To edit ‘maxInMemorySize’ value for the spring service to allow a larger certificate upload, the following information was provided by VMware support:
a. Stop casa.
service vmware-casa stop

b. Edit /usr/lib/vmware-casa/casa-webapp/webapps/casa/WEB-INF/casa-servlet.xml
Locate this text around line 256:
<bean id="multipartResolver" class="org.springframework.web.multipart.commons.CommonsMultipartResolver">
<property name="uploadTempDir" value="file:///${application.data?/storage}/db/tmp"/>
</bean>

Add the following within the <bean> definition:
<property name="maxInMemorySize" value="30720"/>

c. Restart casa.
service vmware-casa start

2) I have been advised that a fix for this issue will be included in the next release, although I cannot confirm that and have no information on the vROps release schedule.

I want to publicly acknowledge VMware Global Support Services (GSS) Business Critical Support (BCS) and the excellent experience working with them to diagnose and resolve this issue, as well as VMware Technical Account Manager (TAM) Services. While not cheap, these service offerings provide high value.

* Update 3/3/2017
vRealize Operations 6.5 was released on 3/2/2017. The 8192 bit certificate size limit is still reflected in the documentation .