Multiple symlink-style issues in the WindowsContainerController and HyperVController controllers in the Docker Desktop for Windows daemon (dockerd). When looking at the WindowsContainerController, they noted the start() and stop() methods as potentially interesting, as they would take start and stop request objects which were attacker-controlled input, and contained a DaemonJSON string, which pointed to the path of the configuration file for docker.

Arbitrary file overwrite/deletion via WindowsContainerController Two fields were of interest in the config, data-root and pidfile. The data-root field is the path to the directory containing container resources. If the directory doesn’t exist, it’ll create it and write files there as SYSTEM. If it already exists, it’ll simply write the files. If an attacker creates the directory beforehand and symlinks to another sensitive directory, they can get a privileged file overwrite as SYSTEM. Similarly, pidfile would be used for writing the PID on start(), or deleting the file on stop(), which was vulnerable to the same issue and also yielded arbitrary file overwrite or deletion respectively.

Arbitrary file overwrite/deletion via HyperVController The HyperV controller had basically the same issues in its create() and destroy() methods. Both would take a diskpath path for creating and deleting a virtual hard disk (vhdk).

Privesc via arbitrary file deletion To escalate privileges from file deletion, they used a known technique documented by ZDI. By deleting the C:\Config.msi directory used for windows installer rollbacks, they could replace rollback scripts (.rbs) with their own to make arbitrary system changes.