Zer0X64

A flaw in the container isolation mechanism of Docker Desktop for Windows and macOS allows local Linux containers to gain unauthenticated access to the Docker Engine API via the configured Docker subnet, typically at '192.168.65.7:2375'. This issue persists regardless of whether Enhanced Container Isolation (ECI) is enabled or if the option to expose the daemon on 'tcp://localhost:2375' without TLS is active. An attacker can exploit this via Server-Side Request Forgery (SSRF) to execute privileged commands, such as managing images and controlling or creating new containers. On Windows systems using the WSL backend, this can lead to a full container escape, allowing the attacker to mount the host drive, read sensitive files, and overwrite system DLLs with the privileges of the user running Docker Desktop. On macOS, while system safeguards provide more protection against unauthorized file access, an attacker can still gain full control over the Docker application and its containers. Technical details include the use of the '/containers/create' and '/containers/{id}/start' API endpoints to deploy privileged containers with host bind mounts.

The issue concerns a non-constant time cryptographic operation, which can be exploited via timing attacks. This allows an attacker to render half of the encryption key obsolete. Successful exploitation downgrades the security guarantees of the XTS mode to those of ECB mode, enabling block swapping and identification of identical blocks. Timing attacks require specific conditions to be exploitable.