Automated VMSA-2021-002 ESXi Workaround with Ansible
Just two days ago at the time of this writing, VMware has released a VMware Security Advisory that is listed as critical VMSA-2021-002 and is recommending that remediation for the vulnerability happen as soon as possible. This is a remote code vulnerability that is especially dangerous. What is the VMSA-2021-002 vulnerability? We will also look at how to apply Automated VMSA-2021-002 ESXi workaround with Ansible so that if you are not able to patch and need to quickly apply the workaround to multiple hosts you can do this.
What is the VMSA-2021-002 Security Advisory?
The VMSA-2021-002 VMware security advisory in part addresses the ESXi OpenSLP heap-overflow vulnerability (CVE-2021-21974). This is part of a collection of vulnerabilities that VMware has deemed critical. The worst of which is a vCenter Server vulnerability that scores 9.8 out of a possible 10.
The VMware vCenter Server updates address remote code execution vulnerability in the vSphere Client (CVE-2021-21972) details are below:
Description
- The vSphere Client (HTML5) contains a remote code execution vulnerability in a vCenter Server plugin. VMware has evaluated the severity of this issue to be in the Critical severity range with a maximum CVSSv3 base score of 9.8.
Known Attack Vectors
- A malicious actor with network access to port 443 may exploit this issue to execute commands with unrestricted privileges on the underlying operating system that hosts vCenter Server.
Resolution
- To remediate CVE-2021-21972 apply the updates listed
The ESXi OpenSLP heap-overflow vulnerability (CVE-2021-21974) is what we are addressing here with Ansible. VMware recommends patching this as it scores 8.8 out of 10 on the severity score. However, as mentioned in the VMSA, if change control or maintenance windows do not align with getting your hosts patched quickly, there is a workaround that involves stopping the OpenSLP service which will no longer allow CIM clients which uses SLP to find CIM servers over port #427 to locate the service.
The workaround is addressed here:
Why dangerous?
A malicious actor residing within the same network segment as ESXi who has access to port 427 may be able to trigger the heap-overflow issue in OpenSLP service resulting in remote code execution.
- A malicious actor residing within the same network segment as ESXi who has access to port 427 may be able to trigger the heap-overflow issue in OpenSLP service resulting in remote code execution.
Automated VMSA-2021-002 ESXi Workaround with Ansible
I wanted to describe how you can use Ansible to implement the workaround as listed in the VMSA-2021-002 KB which is linked to this specific KB on how to stop and disable the OpenSLP service using the steps listed again in the KB below:
In a parent directory, you will work through the steps below:
First create an inventory.yml file like so which contains your ESXi hosts:
[vmware] 10.1.149.13 10.1.149.14 10.1.149.15 10.1.149.16 10.1.149.17
Next, create a group_vars subfolder and create a vmware.yml file there:
ansible_user: root ansible_port: 22 host_key_checking: false
Back to the parent directory, you will create another subfolder called vmware. Inside the vmware folder, create a folder called tasks. In the tasks folder, create a main.yml file.
The contents of the main.yml file are as follows:
---
- name: Security fix https://kb.vmware.com/s/article/76372
shell: |
/etc/init.d/slpd stop
esxcli network firewall ruleset set -r CIMSLP -e 0
chkconfig slpd offWhen you are finished, your folder will look like the following:
To actually run Ansible on your ESXi hosts with the playbook stopping the service, etc., use the following command:
ansible-playbook vmware.yml -v --ask-passThis will prompt you for your SSH password (which needs enabled) and then run the playbook.
Viewing the SLPD service after running the playbook.
Wrapping Up
This is certainly a nasty security vulnerability that needs patched as soon as possible for both vCenter Server and ESXi. Hopefully the above for ESXi will allow you to quickly turn off the SLP service to mitigate the vulnerability until the next maintenance period to apply the recommended updates.
