Summary

A significant vulnerability (CVE-2024-41110) was recently discovered in Docker Engine version 18.09.1.Although the issue was identified and fixed in 2019, the patch did not apply to other major versions, resulting in regression.

The vulnerability was assigned a CVSS score of 10 (critical).

Details About The Vulnerability

Users with access to the Docker daemon can execute any Docker command. To enhance access control, Docker utilizes advanced authorization plugins like AuthZ.

The AuthZ plugin is responsible for approving or denying requests to the Docker daemon based on authentication and the command context. However, security researchers have identified a vulnerability that allows bypassing the AuthZ plugin, leading to privilege escalation.

The flaw occurs when an HTTP request with a Content-Length header set to '0' is sent, which causes the request to be forwarded to the AuthZ plugin without its body, leading to the acceptance of requests that would have ideally been denied!

Basic Architecture Of Access Authorization Plugins

Docker's default authorization model operates on an all-or-nothing basis. Any user who has access to the Docker daemon can execute any Docker client command. 

The same applies to callers using Docker's Engine API. For a more granular access control, you can create and integrate authorization plugins into your Docker daemon configuration. With these plugins, a Docker administrator can set up detailed access policies to manage permissions for interacting with the Docker daemon.

When an HTTP request is sent to the Docker daemon through the CLI or Engine API, it is processed by the authentication subsystem, which then forwards it to the installed authentication plugins. These plugins receive the request along with the user and command context, which are responsible for determining whether to approve or reject the request.

Below are the authorization 'Allow' and 'Deny' diagrams to help clarify the architecture:

Each request sent to the plugin includes the Authenticated User, HTTP headers, and the Request/Response body. However, only the username and authentication method pass on to the plugin.

During request/response processing, certain authorization flows may require additional queries to the Docker daemon. In order to handle these flows, plugins can access the daemon API like regular users can. For these additional queries to work, the plugin must allow administrators to set up appropriate authentication and security policies.

Remediation

The most immediate course of action includes updating the Docker Engine to the most recent version. If users are not able to do so, they can also:

1. Restrict Access to the Docker API:

• Limit access to the Docker API to only trusted parties.
• Implement the principle of least privilege, ensuring that users have the minimum level of access necessary to perform their tasks.

2. Avoid Using AuthZ Plugins:

• Temporarily disable the AuthZ plugins to prevent exploitation of the vulnerability.

Affected versions

• <= v19.03.15, 
• <= v20.10.27, 
• <= v23.0.14, 
• <= v24.0.9, 
• <= v25.0.5, 
• <= v26.0.2, 
• <= v26.1.4, 
• <= v27.0.3, 
• <= v27.1.0

Docker EE v19.03.x and all versions of Mirantis Container Runtime are not vulnerable.