Experts found a Privilege escalation issue in Docker Desktop for Windows

Pierluigi Paganini May 22, 2020

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. 

On May 11, Docker released version 2.3.0.2 that addresses the vulnerability.

“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.

[adrotate banner=”9″][adrotate banner=”12″]

Pierluigi Paganini

(SecurityAffairs – Windows, hacking)

[adrotate banner=”5″]

[adrotate banner=”13″]



you might also like

leave a comment