container:// reference extraction executes the untrusted image instead of extracting from a stopped container

CWEs: CWE-829, CWE-250 CVSS: 7.3 (CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N) Component: openshift-platform/kube-compare

Description When the -r reference path uses the container:// scheme, getReferencesFromContainer pulls the image and starts it with 'podman/docker run -d <image>' solely so that 'cp' can copy the reference directory out. Running (rather than 'create'-ing) the container executes the image's entrypoint/cmd on the operator's workstation. If only docker is available and the daemon socket requires elevation, runEngineCommand wraps the invocation in sudo, so the untrusted entrypoint executes with root-mediated daemon privileges. A reference image name is frequently copy-pasted from documentation or support instructions, making a look-alike malicious image a realistic vector.

Affected Locations - : - :

Evidence pkg/compare/container.go:88-90 — image is executed, not just mounted go // run because copy requires a running or stopped container // -d to output container ID out, err := engine.runEngineCommand("run", "-d", image)

pkg/compare/container.go:61-63 — docker path may run the untrusted image under sudo go if engine.requiresSudo { args = append([]string{engine.name}, args...) out, err = execCommand("sudo", args...).CombinedOutput()

Attack Pattern A malicious or typo-squatted reference image gains arbitrary code execution on the machine running kube-compare (root-equivalent via the docker daemon on the sudo path).

--- Source: Ex-Wing security assessment, finding FIND-001