chore(deps): update dependency containers/podman to v5.1.2

[uniget-bot]

This PR contains the following updates:

Package	Update	Change
containers/podman	patch	5.1.1 -> 5.1.2

---

Warning

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

---

Release Notes

containers/podman (containers/podman)

v5.1.2

Compare Source

Bugfixes

• Fixed a bug that would sometimes prevent the mount of some podman machine volumes into the virtual machine when using the Apple hypervisor (#​22569).
• Fixed a bug where podman top would show the incorrect UID for processes in containers run in a user namespace (#​22293).
• Fixed a bug where the /etc/hosts and /etc/resolv.conf files in a container would be empty after restoring from a checkpoint (#​22901).
• Fixed a bug where the --pod-id-file argument to podman run and podman create did not respect the pod's user namespace (#​22931).
• Fixed a bug in the Podman remote client where specifying a invalid connection in the CONTAINER_CONNECTION environment variable would lead to a panic.

Misc

• Virtual machines run by podman machine using the Apple hypervisor now wait 90 seconds before forcibly stopping the VM, matching the standard systemd shutdown timeout (#​22515).
• Updates the containers/image library to v5.31.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.

[nicholasdille-bot]

Auto-approved because label type/renovate is present.

[github-actions]

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

📦 Image Reference ghcr.io/uniget-org/tools/podman:5.1.2

digest	sha256:753be511763129459691c6694c7e3958e6c2bfea2ca30cfa65049973b92149b7
vulnerabilities
platform	linux/amd64
size	33 MB
packages	172

github.com/opencontainers/runc 1.1.1-0.20240131200429-02120488a4c0 (golang) pkg:golang/github.com/opencontainers/runc@1.1.1-0.20240131200429-02120488a4c0 OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities Affected range <1.2.0-rc.1 Fixed version 1.2.0-rc.1 CVSS Score 7.2 CVSS Vector CVSS: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. OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities Affected range <=v1.1.4 Fixed version Not Fixed CVSS Score 7 CVSS Vector CVSS: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. Improper Preservation of Permissions Affected range <1.1.5 Fixed version 1.1.5 CVSS Score 6.1 CVSS Vector CVSS: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. Incorrect Default Permissions Affected range <1.1.2 Fixed version 1.1.2 CVSS Score 5.9 CVSS Vector CVSS: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: Open an issue Email us at security@opencontainers.org if you think you’ve found a security bug Improper Preservation of Permissions Affected range <1.1.5 Fixed version 1.1.5 CVSS Score 2.5 CVSS Vector CVSS: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: 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) 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

github.com/gorilla/schema 1.3.0 (golang) pkg:golang/github.com/gorilla/schema@1.3.0 Allocation of Resources Without Limits or Throttling Affected range <1.4.1 Fixed version 1.4.1 CVSS Score 7.5 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H Description Details Running schema.Decoder.Decode() on a struct that has a field of type []struct{...} opens it up to malicious attacks regarding memory allocations, taking advantage of the sparse slice functionality. For instance, in the Proof of Concept written below, someone can specify to set a field of the billionth element and it will allocate all other elements before it in the slice. In the local environment environment for my project, I was able to call an endpoint like /innocent_endpoint?arr.10000000.X=1 and freeze my system from the memory allocation while parsing r.Form. I think this line is responsible for allocating the slice, although I haven't tested to make sure, so it's just an educated guess. Proof of Concept The following proof of concept works on both v1.2.0 and v1.2.1. I have not tested earlier versions. package main import ( "fmt" "github.com/gorilla/schema" ) func main() { dec := schema.NewDecoder() var result struct { Arr []struct{ Val int } } if err := dec.Decode(&result, map[string][]string{"arr.1000000000.Val": {"1"}}); err != nil { panic(err) } fmt.Printf("%#+v\n", result) } Impact Any use of schema.Decoder.Decode() on a struct with arrays of other structs could be vulnerable to this memory exhaustion vulnerability. There seems to be no possible solution that a developer using this library can do to disable this behaviour without fixing it in this project, so all uses of Decode that fall under this umbrella are affected. A fix that doesn't require a major change may also be harder to find, since it could break compatibility with some other intended use-cases.

github.com/hashicorp/go-retryablehttp 0.7.6 (golang) pkg:golang/github.com/hashicorp/go-retryablehttp@0.7.6 Insertion of Sensitive Information into Log File Affected range <0.7.7 Fixed version 0.7.7 CVSS Score 6 CVSS Vector CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:C/C:H/I:N/A:N Description go-retryablehttp prior to 0.7.7 did not sanitize urls when writing them to its log file. This could lead to go-retryablehttp writing sensitive HTTP basic auth credentials to its log file. This vulnerability, CVE-2024-6104, was fixed in go-retryablehttp 0.7.7.

[github-actions]

Attempting automerge. See https://github.com/uniget-org/tools/actions/runs/9878106407.

[github-actions]

PR is clean and can be merged. See https://github.com/uniget-org/tools/actions/runs/9878106407.