Dockerfile Misconfiguration: Dependency Confusion

Retrieving build dependencies using a non-specific version can leave the build system vulnerable to malicious binaries or cause the system to experience unexpected behavior.

Dockerfiles can specify an unbound range of versions for dependencies and base images. If an attacker is able to add malicious versions of dependencies to a repository or trick the build system into downloading dependencies from a repository under the attacker's control, if docker is configured without specific versions of dependencies, then docker will silently download and run the compromised dependency.

This type of weakness would be exploitable as a result of a supply chain attack where attackers can leverage misconfiguration by developers, typosquatting and can add malicious packages to open source repositories. An attack of this type exploits the trust in the published packages to gain access and exfiltrate data.

In docker, the latest tag automatically indicates the version level of an image that doesn't use a digest or unique tag to provide a version for it. Docker automatically assigns the latest tag as mechanism to point to the most recent image manifest file. Because tags are mutable, an attacker can replace an image or layer using a latest (or weak tags such as imagename-lst, imagename-last, myimage).

Example 1: The following configuration instructs Docker to pick the base image using the latest version of ubuntu.

    FROM ubuntu:Latest
    ...

Docker does not validate whether the repository configured to support the package manager is trustworthy.

Example 2: The following configuration instructs the package manager zypper to retrive the latest version of the given package.

...
zypper install package
...

In Example 2, if the repository is compromised, an attacker could simply upload a version that meets the dynamic criteria and cause zypper to download a malicious version of the dependency.