Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chore(deps): update dependency containers/podman to v5.2.5 #7895

Merged
merged 1 commit into from
Oct 24, 2024

Conversation

uniget-bot
Copy link

This PR contains the following updates:

Package Update Change
containers/podman patch 5.2.4 -> 5.2.5

Warning

Some dependencies could not be looked up. Check the Dependency Dashboard for more information.


Release Notes

containers/podman (containers/podman)

v5.2.5

Compare Source

Security
  • This release addresses CVE-2024-9675, which allows arbitrary access to the host filesystem from RUN --mount type=cache arguments to a Dockerfile being built.
  • This release also addresses CVE-2024-9676, which allows malicious images with a symlink /etc/passwd or /etc/group to potentially cause a denial of service through reading a FIFO on the host.
Misc
  • Updated Buildah to v1.37.5
  • Updated the containers/storage library to v1.55.1

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.


  • If you want to rebase/retry this PR, check this box

This PR has been generated by Renovate Bot.

Copy link

@nicholasdille-bot nicholasdille-bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Auto-approved because label type/renovate is present.

Copy link

🔍 Vulnerabilities of ghcr.io/uniget-org/tools/podman:5.2.5

📦 Image Reference ghcr.io/uniget-org/tools/podman:5.2.5
digestsha256:d2110d79b7f202a2a31cfcb89d1762754f762797eb7748bdf58607419f828a14
vulnerabilitiescritical: 0 high: 2 medium: 3 low: 2
platformlinux/amd64
size34 MB
packages172
critical: 0 high: 2 medium: 2 low: 2 github.com/opencontainers/runc 1.1.1-0.20240131200429-02120488a4c0 (golang)

pkg:golang/github.com/opencontainers/[email protected]

high 7.2: GHSA--c5pj--mqfh--rvc3 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities

Affected range<1.2.0-rc.1
Fixed version1.2.0-rc.1
CVSS Score7.2
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H
Description

Withdrawn Advisory

This advisory has been withdrawn because it was incorrectly attributed to runc. Please see the issue here for more information.

Original Description

A flaw was found in cri-o, where an arbitrary systemd property can be injected via a Pod annotation. Any user who can create a pod with an arbitrary annotation may perform an arbitrary action on the host system. This issue has its root in how runc handles Config Annotations lists.

high 7.0: CVE--2023--27561 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities

Affected range<=v1.1.4
Fixed versionNot Fixed
CVSS Score7
CVSS VectorCVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
Description

runc through 1.1.4 has Incorrect Access Control leading to Escalation of Privileges, related to libcontainer/rootfs_linux.go. To exploit this, an attacker must be able to spawn two containers with custom volume-mount configurations, and be able to run custom images. NOTE: this issue exists because of a CVE-2019-19921 regression.

medium 6.1: CVE--2023--28642 Improper Preservation of Permissions

Affected range<1.1.5
Fixed version1.1.5
CVSS Score6.1
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:L
Description

Impact

It was found that AppArmor, and potentially SELinux, can be bypassed when /proc inside the container is symlinked with a specific mount configuration.

Patches

Fixed in runc v1.1.5, by prohibiting symlinked /proc: opencontainers/runc#3785

This PR fixes CVE-2023-27561 as well.

Workarounds

Avoid using an untrusted container image.

medium 5.9: CVE--2022--29162 Incorrect Default Permissions

Affected range<1.1.2
Fixed version1.1.2
CVSS Score5.9
CVSS VectorCVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L
Description

Impact

A bug was found in runc where runc exec --cap executed processes 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.

Patches

This bug has been fixed in runc 1.1.2. Users should update to this version as soon as possible.

This fix changes runc exec --cap behavior such that the additional capabilities granted to the process being executed (as specified via --cap arguments) do not include inheritable capabilities.

In addition, runc spec is changed to not set any inheritable capabilities in the created example OCI spec (config.json) file.

Credits

The opencontainers project would like to thank Andrew G. Morgan for responsibly disclosing this issue in accordance with the opencontainers org security policy.

For more information

If you have any questions or comments about this advisory:

low 3.6: CVE--2024--45310 Race Condition Enabling Link Following

Affected range<1.1.14
Fixed version1.1.14
CVSS Score3.6
CVSS VectorCVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:N/SC:N/SI:L/SA:N/U:Green
Description

Impact

runc 1.1.13 and earlier as well as 1.2.0-rc2 and earlier can be tricked into
creating empty files or directories in arbitrary locations in the host
filesystem by sharing a volume between two containers and exploiting a race
with os.MkdirAll. While this can be used to create empty files, existing
files will not be truncated.

An attacker must have the ability to start containers using some kind of custom
volume configuration. Containers using user namespaces are still affected, but
the scope of places an attacker can create inodes can be significantly reduced.
Sufficiently strict LSM policies (SELinux/Apparmor) can also in principle block
this attack -- we suspect the industry standard SELinux policy may restrict
this attack's scope but the exact scope of protection hasn't been analysed.

This is exploitable using runc directly as well as through Docker and
Kubernetes.

The CVSS score for this vulnerability is
CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:N/I:L/A:N (Low severity, 3.6).

Workarounds

Using user namespaces restricts this attack fairly significantly such that the
attacker can only create inodes in directories that the remapped root
user/group has write access to. Unless the root user is remapped to an actual
user on the host (such as with rootless containers that don't use
/etc/sub[ug]id), this in practice means that an attacker would only be able to
create inodes in world-writable directories.

A strict enough SELinux or AppArmor policy could in principle also restrict the
scope if a specific label is applied to the runc runtime, though we haven't
thoroughly tested to what extent the standard existing policies block this
attack nor what exact policies are needed to sufficiently restrict this attack.

Patches

Fixed in runc v1.1.14 and v1.2.0-rc3.

Credits

Thanks to Rodrigo Campos Catelin (@rata) and Alban Crequy (@alban) from
Microsoft for discovering and reporting this vulnerability.

low 2.5: CVE--2023--25809 Improper Preservation of Permissions

Affected range<1.1.5
Fixed version1.1.5
CVSS Score2.5
CVSS VectorCVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:C/C:N/I:N/A:L
Description

Impact

It was found that rootless runc makes /sys/fs/cgroup writable in following conditons:

  1. when runc is executed inside the user namespace, and the config.json does not specify the cgroup namespace to be unshared (e.g.., (docker|podman|nerdctl) run --cgroupns=host, with Rootless Docker/Podman/nerdctl)
  2. or, when runc is executed outside the user namespace, and /sys is mounted with rbind, ro (e.g., runc spec --rootless; this condition is very rare)

A container may gain the write access to user-owned cgroup hierarchy /sys/fs/cgroup/user.slice/... on the host .
Other users's cgroup hierarchies are not affected.

Patches

v1.1.5 (planned)

Workarounds

  • Condition 1: Unshare the cgroup namespace ((docker|podman|nerdctl) run --cgroupns=private). This is the default behavior of Docker/Podman/nerdctl on cgroup v2 hosts.
  • Condition 2 (very rare): add /sys/fs/cgroup to maskedPaths
critical: 0 high: 0 medium: 1 low: 0 github.com/containers/buildah 1.37.5 (golang)

pkg:golang/github.com/containers/[email protected]

medium : CVE--2024--9407

Affected range>=0
Fixed versionNot Fixed
Description

Improper Input Validation in Buildah and Podman in github.com/containers/buildah

Copy link

Copy link

@github-actions github-actions bot merged commit cb75942 into main Oct 24, 2024
10 of 11 checks passed
@github-actions github-actions bot deleted the renovate/containers-podman-5.2.x branch October 24, 2024 02:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants