VMware has released an update to address a privilege escalation flaw in VMware for the macOS version of Fusion that was introduced by a previous patch.
In March, VMware patched a high-severity privilege escalation vulnerability (CVE-2020-3950) in Fusion, Remote Console (VMRC) and Horizon Client for Mac.
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 flaw was reported by Jeffball of GRIMM and Rich Mirch, VMware assigned it a CVSSv3 base score of 7.3 and rated it as Important severity. The issue impacts Fusion (11.x before 11.5.2), Remote Console for Mac (11.x and prior before 11.0.1) and Horizon Client for Mac (5.x and prior before 5.4.0) macOS apps.
Mirch and Jeffball, immediately noted that the patch issued by VMware was incomplete, VMware confirmed it a few days later and released a new patch at the end of March. Unfortunately the new fix introduced a new security issue.
The vulnerability introduced by the second patch, tracked as CVE-2020-3957, is a time-of-check time-of-use (TOCTOU) issue that could allow attackers with low permissions to execute arbitrary code with root privileges.
Last week, the company releases version 11.5.5, but the issue for VMRC and Horizon Client for Mac are yet to be approved.
A severe privilege escalation vulnerability, tracked as CVE-2020-11492, has been addressed in the Windows Docker Desktop Service.
Cybersecurity researchers from Pen Test Partners publicly disclosed a privilege escalation vulnerability in the Windows Docker Desktop Service.
The CVE-2020-11492 issue affects the way the service uses named pipes when communicating as a client to child processes.
“Docker Desktop for Windows suffers from a privilege escalation vulnerability to SYSTEM. The core of the issue lies with the fact that the Docker Desktop Service, the primary Windows service for Docker, communicates as a client to child processes using named pipes.” reads the analysis published by Pen Test Partners.
“The high privilege Docker Desktop Service can be tricked into connecting to a named pipe that has been setup by a malicious lower privilege process. Once the connection is made, the malicious process can then impersonate the Docker Desktop Service account (SYSTEM) and execute arbitrary system commands with the highest level privileges.”
Experts discovered that the Docker Desktop Service can be tricked by attackers into connecting to a named pipe that has been set up by a malicious lower privilege process. Then the process can impersonate the Docker Desktop Service account and execute arbitrary commands with the highest privileges.
Upon installing Docker Desktop for Windows, a service called Docker Desktop Service is installed and runs by default, waiting for the Docker Desktop application to start.
Once the Docker software is started it will create several child processes to manage several functions such as process monitoring and image creation. Windows OS uses pipes for inter-process communication (IPC).
Named pipes could allow the server side of the connection to impersonate the client account who is connecting. The impersonation functionality allows the service to drop its credentials in favour of the connecting client. Experts pointed out that when restricted operating system functionalities and files are requested, the action is performed under the impersonated account and not the service account that the process was launched under.
This specific right is dubbed “Impersonate a client after authentication,” and is assigned to specific accounts by default including admin, network service, IIS App Pool, and Microsoft SQL Server Account.
“By default, services that are started by the Service Control Manager have the built-in Service group added to their access tokens. Component Object Model (COM) servers that are started by the COM infrastructure and that are configured to run under a specific account also have the Service group added to their access tokens. As a result, these services get this user right when they are started.” continues the post.
“Anything started by the Service Control Manager will automatically get the impersonation privilege, no matter which account is used to start the service.“
Experts discovered that an attacker that is able to execute code under the context of a process with the above privileges, could set up a malicious pipe to compromise the software and elevate their privileges to system-level.
Experts pointed out that attackers need Administrator rights to create such a service.
“Let’s say you happen to be hosting a vulnerable IIS Web Application on the same machine as Docker for Windows,” continues the analysis.”This could be one example of a successful attack vector. The initial attack vector could utilize a vulnerability in the web application to perform code execution under the limited IIS App Pool account.”
The researchers sent the details to the Docker security team on March 25, that initially said impersonation is a Windows feature and reported the issue to Microsoft.
Experts provided a Proof-of-Concept (PoC) to Docker that finally acknowledged it on April 1.
“After a few emails back and forth, then finally submitting a working PoC, Docker did agree that it was a security vulnerability and as such have now issued a fix. When the Docker service process connects to the named pipes of spawned child processes it now uses the SecurityIdentification impersonation level. This will allow the server end of the pipe to get the identity and privileges of the client but not allow impersonation.” Pen Test Partners concludes.