VMware warns of critical remote code execution flaw in vSphere HTML5 client
- Reference: 1614123312
- News link: https://www.theregister.co.uk/2021/02/23/vmware_vsphere_critical_bugs/
- Source link:
“The vSphere Client (HTML5) contains a remote code execution vulnerability in a vCenter Server plugin,” says VMware’s [1]notification . “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.”
[2]
As vCenter Server is the tool that drives a fleet of virtual servers, this CVSS 9.8-rated bug (CVE-2021-21972) is nasty.
A fix, detailed [3]here , is needed for vSphere versions prior to 7.0 U1c, 6.7 U3l, and 6.5 U3n. As those releases are all at least a few weeks old, users may already have addressed the issue. Users of Cloud Foundation 3.x and 4.x also need to get patching, pronto.
[4]
While you’re patching that nasty, you may as well also knock off a second HTML client bug (CVE-2021-21973) that VMware says could allow: “A malicious actor with network access to port 443 may exploit this issue by sending a POST request to vCenter Server plugin leading to information disclosure.”
The same versions of vSphere and Cloud Foundation mentioned above need fixing, with details and downloads to do so on offer [5]here .
Your work’s not done once that’s sorted because VMware has also fixed up an 8.8-rated flaw (CVE-2021-21974) in its ESXi hypervisor that means: “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.”
Dying software forces changes to VMware’s vSphere Clients [6]READ MORE
OpenSLP is an open-source version of the IETF Service Location Protocol. Details of how to fix that little mess can be found [7]here and demand your attention if you run vSphere 6.5 and up, or Cloud Foundation 3 or higher. VMware’s recent [8]update to its guidance on vSphere security recommended disabling OpenSLP if it’s not in use. But that guidance only emerged two weeks ago.
VMware has tipped its hat to Mikhail Klyuchnikov of Positive Technologies for the vSphere client bugs and Lucas Leong of Trend Micro's Zero Day Initiative for the OpenSLP bug.
VMware’s HTML5 client replaced a Flash-based tool, because Virtzilla knew that Adobe's buggy mess was [9]on death row . The HTML5 client oozed out over years, only achieving feature parity more than two years after initial release.
[10]
Today’s bugs won’t leave vAdmins pining for the good old days of Flash, but with a new UI for ESXi in the works, they’ll need to remain vigilant. ®
Get our [11]Tech Resources
[1] https://www.vmware.com/security/advisories/VMSA-2021-0002.html
[2] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2YDXdbweHQnmFgcsoIwdeqAAAANI&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[3] https://kb.vmware.com/s/article/82374
[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33YDXdbweHQnmFgcsoIwdeqAAAANI&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[5] https://kb.vmware.com/s/article/82374
[6] https://www.theregister.com/2020/09/21/vmware_client_upgrades/
[7] https://kb.vmware.com/s/article/76372
[8] https://www.theregister.com/2021/02/11/new_vsphere_7_security_guidance/
[9] https://www.theregister.com/2021/01/12/flash_is_dead/
[10] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44YDXdbweHQnmFgcsoIwdeqAAAANI&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[11] https://whitepapers.theregister.com/
kill openSLP
FYI you can run this command to see if the SLP service is even being used (at least on vSphere 6): esxcli system slp stats get
to see stats about SLP, assuming it is accurate, when I disabled SLP on my clusters back in October the stats indicated no hits to the service since the system started(assuming some kind of health check that ran when the hypervisor booted, time stamp of the event matches boot time exactly).
vmware suggested in the past to disable SLP if you are not using it as a "workaround" though they implied(as of Oct 2020, though looking now looks like they have removed that language, tried checking archive.org for the older page but page was just a blank page) that may break stuff so it's not a long term solution(for me based on the stats of that command, it is a long term solution don't think that feature has ever been used at the orgs I have worked at):
https://kb.vmware.com/s/article/76372
as an extra check I ran nmap against the hosts to verify the port was closed after making the change.
Oozed
"The HTML5 client oozed out over years, only achieving feature parity more than two years after initial release."
To be fair, they are supporting 6.0, 6.5, 6.7 and 7.0 which is a huge burden. See https://lifecycle.vmware.com/#/
They did the initial client in fat form on client a la HyperV but without the MMC bollocks. That worked well and was fast *sigh*. Then we got a sodding huge lump of Flash stuff. Quite fast once it wheezed into life (5-20 mins from start), quite buggy, very odd in its initial incarnations. Got better and was very stable in its last incarnations. The HTML5 jobbie grew up rather ginger but has improved and despite being rather drab still, is now pretty decent. The local host webby interface is nearly good enough nowadays and stable but all of VMware's webby things are still a bit odd in places. Not BES (shudder) odd or Cisco firewall odd or HPE Procurve odd or Fritzbox odd but still quite ... odd.