Docker Engine < v27.1.1 - System Takeover via Authorization Bypass Vulnerability in API (CVE-2024-41110)

Background & Context

Docker is a set of platform as a service (PaaS) products that use OS-level virtualization to deliver software in packages called containers. The Docker daemon, called dockerd, is a persistent process that manages Docker containers and handles container objects. The daemon listens for requests sent via the Docker Engine API (also known as Docker CE).

Docker’s default authorization model is all-or-nothing. Users with access to the Docker daemon can execute any Docker command. For greater access control, authorization plugins (AuthZ) can be used. These plugins approve or deny requests to the Docker daemon based on authentication and command context.

Vulnerability Summary

A security vulnerability has been detected in certain versions of Docker Engine in request authorization handling by the Docker Engine API. Using a specially-crafted API request with an HTTP Content-Length header value of 0, an Engine API client could make the daemon forward the request or response to the AuthZ authorization plugin without an accompanying request body containing the authorization request details. In normal (intended) operation, API requests include a body that contains the necessary data for the request to be evaluated, and the authorization plugin inspects this body to make access control decisions. When the Content-Length header is set to 0, the request is forwarded to the AuthZ plugin without the body, so the plugin cannot perform proper validation.

NOTE: this issue was originally fixed in Docker Engine release v18.09.1 in January 2019. However, from 2019-07-22 onwards, the fix was not carried forward to later versions of the upstream Moby project source code, resulting in a regression present in all future releases. Anyone who depends on authorization plugins that introspect the request and/or response body to make access control decisions is potentially impacted.

Impact If Exploited

The vulnerability can be exploited in order to cause the authorization plugin to allow a request which it would have otherwise denied if the body had been forwarded to it as intended by design. Exploit could therefore allow an attacker to bypass authorization plugin (AuthZ) access control decisions under specific circumstances. This entails the risk of the Docker Engine API approving requests for actions by unauthorised users, including unauthorised system access and privilege escalation.

NOTE: This vulnerability has not to date been been reported by the CISA (America's Cyber Defense Agency) to be known to be currently actively exploited in the wild as of 2024-07-25 although the exploit is relatively trivial. Docker holds a substantial portion of the containerisation market share. Considering that threat actors typically employ a blend of probability and asset value when identifying potential attack surfaces, container-based products like Docker could become a primary target. As Docker containers have become a crucial component of many business infrastructures, threat actors are likely to continue exploiting vulnerabilities in associated products in attempts to extract the sensitive data they contain. Prioritisation should be given to remediation in any impacted environment.

Affected Product Versions

Any software that is a fork of the upstream Moby Project is impacted. This primarily involves the open-source CE (Community Edition) release of Docker, as detailed below, and not commercial (Mirantis) distributions:

• Docker Engine CE (Community Edition) versions up to v19.03.15, v20.10.27, v23.0.14, v24.0.9, v25.0.5, v26.0.2, v26.1.4, v27.0.3, and v27.1.0

• Docker Desktop up to v4.32.0 includes affected versions of Docker Engine. The impact for Docker Desktop is limited compared to production environments

• Mirantis Container Runtime (MCR, formerly Docker Enterprise) is NOT vulnerable.

Indicators of Compromise (IoC)

The vendor has not published a list of indicators of compromise (IoC) at the time of writing.

Official Fix & Remediation Guidance

• Docker Engine v27.1.1 contains patches to fix the vulnerability. Patches have also been merged into the master, 19.0, 20.0, 23.0, 24.0, 25.0, 26.0, and 26.1 release branches. Users are advised to upgrade as soon as possible to patched versions v23.0.14 and v27.1.1 or later. Updates can be obtained via the Docker download site or directly from Docker Engine source code.

• Docker Desktop v4.33 will contain a patched version of Docker Engine. If using an affected version, update to Docker Desktop 4.33 after it is released.

NOTE: Remediation of this vulnerability by patching to a specific version indicated may not be sufficient to secure the product against further vulnerabilities discovered in later versions, subsequent to the publication of this guidance. Unless contra-indicated, customers are therefore advised to always upgrade to the latest version of the product available.

Temporary Mitigation & Workarounds

If an immediate upgrade is not possible, then it is recommended to apply the following temporary mitigations:

• Avoid using AuthZ plugins for authorization decisions.

• Restrict access to the Docker API to trusted parties, following the principle of least privilege. Docker also cautions against exposing the Docker API over TCP networks without protection.

• Docker Business subscribers can use Settings Management to enforce secure settings.

NOTE: Caution should always be taken in applying any temporary mitigations listed. Mitigations are only recommended in cases where patches to remediate the vulnerability are not available, or cannot safely be applied to a given environment immediately. A given mitigation may not in all cases be recommended officially by the application vendor. The viability of any given temporary mitigation measure may vary, depending on server platform and existing configuration. Mitigations listed may incompletely remediate any given vulnerability. Configuration changes to implement listed mitigations may impact/disrupt required functionality within a given customer application. Care should therefore be taken to carefully analyse any listed mitigations for appropriateness to a given environment. Customers are advised to test any configuration changes prior to their being introduced into a production environment.

Vendor Advisory

• https://www.docker.com/blog/docker-security-advisory-docker-engine-authz-plugin/

• https://github.com/moby/moby/security/advisories/GHSA-v23v-6jw2-98fq

• https://github.com/moby/moby/commit/fc274cd2ff4cf3b48c91697fb327dd1fb95588fb

• https://www.mirantis.com/blog/mirantis-container-runtime-fixes-docker-engine-vulnerability-affecting-upstream-moby

• https://github.com/Mirantis/security/blob/main/advisories/0013.md

Third-Party Analysis

• https://thehackernews.com/2024/07/critical-docker-engine-flaw-allows.html

PoC and Exploit Code

• TBC