Build filesystem sync discloses host files outside the build context via symlinks

## Impact `container build` involves two things the host does not fully trust: the build context (the Dockerfile and files a user points the build at) and the builder peer (the BuildKit process the host's build daemon talks to over a gRPC stream — normally a stock image, but replaceable via `build.image` in `container`'s config, or compromised via a supply-chain attack on that image). `container build`'s own host-side code is trusted; neither of the parties it talks to is. A malicious builder peer may be able to request an in-context file by name from the host and receive the contents of whatever the name resolves to, even when it resolves outside the build context. The host-side actor that serves these requests, enforces containment on the lexical path of the requested name — it checks whether the name is textually inside the context directory, not whether the file it ultimately resolves to is. This is exploitable when the build context also contains a symlink whose target lies outside it. ## Affected code Affected functions: `BuildFSSync.read()` and `BuildFSSync.info()` in `Sources/ContainerBuild/BuildFSSync.swift`, present with this defect since the file was introduced (initial commit, 2025-06-03). **Not affected:** `BuildFSSync.walk()`, the primary path a stock builder uses to transfer the bulk of build-context files, already enforced a resolved-path-independent lexical check at the same call sites; a related but distinct symlink-handling gap in `walk()`/`Globber` is tracked separately. ## Mitigations 1. Upgrade to `container` 1.2.0 or later. 2. If you cannot upgrade immediately, only build with the default, unmodified builder — do not set a custom `build.image` in `container`'s configuration unless you trust its publisher as much as you trust the `container` project itself. This finding requires a builder peer willing to make direct file requests outside normal Dockerfile processing; the stock builder does not do this except in a narrow startup race window. 3. Avoid running `container build` against build contexts you did not author yourself or have not reviewed, as a second layer of defense — a compromised builder peer can only reach an out-of-context file this way if the context also contains a symlink pointing at it. 4. Before building a cloned or downloaded context, scan it for symlinks that resolve outside the context root: ``` find <context-dir> -type l -exec sh -c 'case "$(readlink -f "$1")" in "$2"/*) ;; *) echo "$1 -> $(readlink -f "$1")";; esac' _ {} <context-dir> \; ``` Remove or replace any symlink whose target falls outside the context before building. ## Verifying whether you are affected This does not leave a durable artifact to scan for after the fact, since the disclosure happens in-memory during the build rather than writing a marker to the host filesystem. There is also no reliable way to check whether your builder peer itself is trustworthy short of controlling its provenance directly — this check only covers the build-context half of the precondition, not the builder-peer half. To check whether a specific build context contains the symlink shape this depends on, inspect it without building: ``` find <context-dir> -type l | while read -r l; do case "$(readlink -f "$l")" in "$(readlink -f <context-dir>)"/*) ;; *) echo "escapes context: $l -> $(readlink -f "$l")";; esac done ``` Any symlink reported by this command, combined with a builder peer willing to request it directly, was capable of having its target's contents disclosed on affected versions. Separately, check `container system property ls` or your `~/.config/container/config.toml` for a non-default `build.image` — using one you don't fully trust is the other half of the precondition. ## References - Fix: [apple/container#2027](https://github.com/apple/container/pull/2027)

Severity from

GitHub (reviewed advisory)

• github.com/apple/container/security/advisories/GHSA-2v2q-4q35-h585
• github.com/apple/container