Impact When using a custom BuildKit frontend, the frontend can craft an API message that causes files to be written outside of the BuildKit state directory for the execution context.

Patches The issue has been fixed in v0.28.1+

Workarounds Issue requires using an untrusted BuildKit frontend set with #syntax or --build-arg BUILDKITSYNTAX. Using these options with a well-known frontend image like docker/dockerfile is not affected.

BuildKit is a toolkit for converting source code to build artifacts in an efficient, expressive and repeatable manner. In affected versions when the user sends a build request that contains a Git URL that contains credentials and the build creates a provenance attestation describing that build, these credentials could be visible from the provenance attestation. Git URL can be passed in two ways: 1) Invoking build directly from a URL with credentials. 2) If the client sends additional version control system (VCS) info hint parameters on builds from a local source. Usually, that would mean reading the origin URL from .git/config file. When a build is performed under specific conditions where credentials were passed to BuildKit they may be visible to everyone who has access to provenance attestation. Provenance attestations and VCS info hints were added in version v0.11.0. Previous versions are not vulnerable. In v0.10, when building directly from Git URL, the same URL could be visible in BuildInfo structure that is a predecessor of Provenance attestations. Previous versions are not vulnerable. This bug has been fixed in v0.11.4. Users are advised to upgrade. Users unable to upgrade may disable VCS info hints by setting BUILDXGITINFO=0. buildctl does not set VCS hints based on .git directory, and values would need to be passed manually with --opt.

Impact Insufficient validation of Git URL fragment subdir components (<url>#<ref>:<subdir>, docs) may allow access to files outside the checked-out Git repository root. Possible access is limited to files on the same mounted filesystem.

Patches The issue has been fixed in version v0.28.1

Workarounds The issue affects only builds that use Git URLs with a subpath component. Avoid building Dockerfiles from untrusted sources or using the subdir component from an untrusted Git repository where the subdir component could point to a symlink.

Impact A malicious BuildKit frontend or Dockerfile using RUN --mount could trick the feature that removes empty files created for the mountpoints into removing a file outside the container, from the host system.

Patches The issue has been fixed in v0.12.5

Workarounds Avoid using BuildKit frontend from an untrusted source or building an untrusted Dockerfile containing RUN --mount feature.

References

Impact A malicious BuildKit client or frontend could craft a request that could lead to BuildKit daemon crashing with a panic.

Patches The issue has been fixed in v0.12.5

Workarounds Avoid using BuildKit frontends from untrusted sources. A frontend image is usually specified as the #syntax line on your Dockerfile, or with --frontend flag when using buildctl build command.

References

Impact In addition to running containers as build steps, BuildKit also provides APIs for running interactive containers based on built images. It was possible to use these APIs to ask BuildKit to run a container with elevated privileges. Normally, running such containers is only allowed if special security.insecure entitlement is enabled both by buildkitd configuration and allowed by the user initializing the build request.

Patches The issue has been fixed in v0.12.5 .

Workarounds Avoid using BuildKit frontends from untrusted sources. A frontend image is usually specified as the #syntax line on your Dockerfile, or with --frontend flag when using buildctl build command.

References

Impact Two malicious build steps running in parallel sharing the same cache mounts with subpaths could cause a race condition that can lead to files from the host system being accessible to the build container.

Patches The issue has been fixed in v0.12.5

Workarounds Avoid using BuildKit frontend from an untrusted source or building an untrusted Dockerfile containing cache mounts with --mount=type=cache,source=... options.

References https://www.openwall.com/lists/oss-security/2019/05/28/1

A custom client can produce such an upload request to the BuildKit daemon that files can escape from the BuildKit-controlled state directory. The client needs to have valid permissions to access the BuildKit control API to issue builds, e.g., bypass authentication, etc.

BuildKit's cache mount source= selector on Windows Container on Windows (WCOW) workers does not detect NTFS directory junctions placed inside the cache root. A build authored by an untrusted user on a WCOW-configured BuildKit daemon can read arbitrary host files reachable to the BuildKit daemon process.

BuildKit custom frontends or clients using the raw low-level API can set git.checkoutbundle=true when checking out Git sources. If the Git source is malicious, this could lead to a crafted command invocation on the host.

A malicious BuildKit client or frontend could craft a request that could lead to BuildKit daemon crashing with a panic.

A crafted message in the BuildKit low-level build API can be used to remove the contents of the /tmp directory. The action that can normally be used to delete files inside the build container rootfs can escape into the real host temp directory.