VMware warns of critical remote code execution flaw in vSphere HTML5 client VMware has revealed a critical-rated bug in the HTML5 client for its flagship vSphere hybrid cloud suite. "The vSphere Client (HTML5) contains a remote code execution vulnerability in a vCenter Server plugin," says VMware's notification. "A malicious actor with network access to port 443 may exploit this issue to execute …
"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.
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.
Why is historical old flash client even brought up in the article?
Is it, "we never had problems with the old setup so it must be the new UI that is the issue"?
Sort of like the eternal IT quote "it always worked before you upgraded it".
People always forget that the old setup had its own issues all the time too.
Probably because it took them forever to replace despite the exceedingly long death notice on Flash. During 2018 I remember discussing with a vSphere admin friend if he thought the HTML5 client would manage to achieve parity with the Flash client before Adobe killed Flash. He was doubtful.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
