Security firm Guardicore released technical information on a critical VMware vCenter Server vulnerability recently disclosed by VMware.
Earlier this month, VMware has addressed a critical information disclosure flaw, tracked as CVE-2020-3952, that could be exploited by attackers to compromise vCenter Server or other services that use the Directory Service (vmdir) for authentication.
The CVE-2020-3952 vulnerability has received a CVSSv3 score of 10, it resides in the vCenter Server version 6.7 on Windows and virtual appliances.
According to VMware, the vulnerability could be exploited only on vCenter Server installs that ware upgraded from a previous version. Clean installs of vCenter Server 6.7 (embedded or external PSC) are not impacted. At the time, VMware did not disclose technical details about the vulnerability.
The vulnerability has been addressed with the release of the 6.7u3f update.
“A sensitive information disclosure vulnerability in the VMware Directory Service (vmdir) was privately reported to VMware. vCenter updates are available to address this vulnerability.” reads the advisory published by WMware. “Under certain conditions1 vmdir that ships with VMware vCenter Server, as part of an embedded or external Platform Services Controller (PSC), does not correctly implement access controls. VMware has evaluated the severity of this issue to be in the Critical severity range with a maximum CVSSv3 base score of 10.0.”
Now experts at Guardicore analyzed the patch issued by VMware and released the technical analysis of the vulnerability.
An attacker with network access to a vCenter Server LDAP service can exploit the issue to create a user with full privileges on the vCenter Directory gaining full control over the VMware deployment.
“We were able to implement a proof of concept for this exploit that enacts a remote takeover of the entire
“The vulnerability is enabled by two critical issues in vmdir’s legacy LDAP handling code:
- A bug in a function named VmDirLegacyAccessCheck which causes it to return “access granted” when permissions checks fail.
- A security design flaw which grants root privileges to an LDAP session with no token, under the assumption that it is an internal operation.”
Guardicore speculates WMware was aware of the issue, but for some reason, it failed to address it.
“Despite the relative clarity of VMware’s code, it looks like there were quite a few missteps that went into the vulnerability. The developers were at least partially aware of them, too, as we saw in the code comments and commit messages.” continues Guardicore.
“The fix to VmDirLegacyAccessCheck isn’t any more than band-aid — had VMware looked into this bug in-depth they would have found a series of issues that need to be addressed: the strange semantics of bIsAnonymousBind, the disastrous handling of pAccessToken, and, of course, the bug we started from, in VmDirLegacyAccessCheck.”
Experts highlighted that the bugfix to VmDirLegacyAccessCheck was written nearly three years ago, and the company only now released it.
“Three years is a long time for something as critical as an LDAP privilege escalation not to make it into the release schedule — especially when it turns out to be much more than a privilege escalation,” the experts conclude.
In March, VMware has released security updates to address high severity privilege escalation and denial-of-service (DoS) flaws in the Workstation, Fusion, Remote Console and Horizon Client.
The two security vulnerabilities have been tracked as CVE-2020-3950 and CVE-2020-3951 respectively.
The CVE-2020-3950 is a privilege escalation vulnerability caused by the improper use of setuid binaries, it could be exploited by attackers to escalate privileges to root.
The CVE-2020-3951 vulnerability is a denial-of-service issue caused by a heap-overflow issue in Cortado Thinprint.
| [adrotate banner=”9″] | [adrotate banner=”12″] |
(
[adrotate banner=”5″]
[adrotate banner=”13″]
