chore(deps): update dependency rancher/rke to v1.5.10

[uniget-bot]

This PR contains the following updates:

Package	Update	Change
rancher/rke	patch	1.5.9 -> 1.5.10

---

Warning

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

---

Release Notes

rancher/rke (rancher/rke)

v1.5.10

Compare Source

Rancher Kubernetes Engine (RKE) is a CNCF-certified Kubernetes distribution that runs entirely within Docker containers. It works on bare-metal and virtualized servers. With RKE, the installation and operation of Kubernetes are both simplified and easily automated, and they are entirely independent of the operating system and platform you're running.

RKE Kubernetes versions

• v1.25.16-rancher2-3
• v1.26.15-rancher1-1
• v1.27.14-rancher1-1
• v1.28.10-rancher1-1 (default)

---

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/rke:1.5.10

📦 Image Reference ghcr.io/uniget-org/tools/rke:1.5.10

digest	sha256:9b30f29a5182b1cac11b2c22e80cb7e0f0e68873cb110e10ce186e8b178cb995
vulnerabilities
platform	linux/amd64
size	18 MB
packages	123

github.com/opencontainers/runc 1.1.12 (golang) pkg:golang/github.com/opencontainers/runc@1.1.12 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 <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 On CRI-O, an arbitrary systemd property can be injected via a Pod annotation: --- apiVersion: v1 kind: Pod metadata: name: poc-arbitrary-systemd-property-injection annotations: </blockquote> </details> </details></td></tr> <tr><td valign="top"> <details><summary><img alt="critical: 0" src="https://img.shields.io/badge/C-0-lightgrey"/> <img alt="high: 1" src="https://img.shields.io/badge/H-1-e25d68"/> <img alt="medium: 0" src="https://img.shields.io/badge/M-0-lightgrey"/> <img alt="low: 0" src="https://img.shields.io/badge/L-0-lightgrey"/> <!-- unspecified: 0 --><strong>github.com/rancher/norman</strong> <code>0.0.0-20240206180703-6eda4bc94b4c</code> (golang)</summary> <small><code>pkg:golang/github.com/rancher/norman@0.0.0-20240206180703-6eda4bc94b4c</code></small><br/> <a href="https://scout.docker.com/v/CVE-2023-32193?s=github&n=norman&ns=github.com%2Francher&t=golang&vr=%3C0.0.0-20240207153100-3bb70b772b52"><img alt="high 8.3: CVE--2023--32193" src="https://img.shields.io/badge/CVE--2023--32193-lightgrey?label=high%208.3&labelColor=e25d68"/></a> <i>Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS)</i> <table> <tr><td>Affected range</td><td><code><0.0.0-20240207153100-3bb70b772b52</code></td></tr> <tr><td>Fixed version</td><td><code>0.0.0-20240207153100-3bb70b772b52</code></td></tr> <tr><td>CVSS Score</td><td><code>8.3</code></td></tr> <tr><td>CVSS Vector</td><td><code>CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:L</code></td></tr> </table> <details><summary>Description</summary> <blockquote> ### Impact A vulnerability has been identified in which unauthenticated cross-site scripting (XSS) in Norman's public API endpoint can be exploited. This can lead to an attacker exploiting the vulnerability to trigger JavaScript code and execute commands remotely. The attack vector was identified as a Reflected XSS. Norman API propagates malicious payloads from user input to the UI, which renders the output. For example, a malicious URL gets rendered into a script that is executed on a page. The changes addressed by this fix are: - Encode input that comes from the request URL before adding it to the response. - The request input is escaped by changing the URL construction that is used for links to use `url.URL`. - The request input is escaped by escaping the JavaScript and CSS variables with attribute encoding as defined by [OWASP](https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html#output-encoding-rules-summary). ### Patches Patched versions include the following commits: | Branch | Commit | | -------- | ------- | | master | 3bb70b7 | | release/v2.8 | a6a6cf5 | | release/v2.7 | cb54924 | | release/v2.7.s3 | 7b2b467 | | release/v2.6 | bd13c65 | ### Workarounds There is no direct mitigation besides updating Norman API to a patched version. ### References If you have any questions or comments about this advisory: - Reach out to the [SUSE Rancher Security team](https://github.com/rancher/rancher/security/policy) for security-related inquiries. - Open an issue in the [Rancher](https://github.com/rancher/rancher/issues/new/choose) repository. - Verify with our [support matrix](https://www.suse.com/suse-rancher/support-matrix/all-supported-versions/) and [product support lifecycle](https://www.suse.com/lifecycle/). </blockquote> </details> </details></td></tr> <tr><td valign="top"> <details><summary><img alt="critical: 0" src="https://img.shields.io/badge/C-0-lightgrey"/> <img alt="high: 0" src="https://img.shields.io/badge/H-0-lightgrey"/> <img alt="medium: 3" src="https://img.shields.io/badge/M-3-fbb552"/> <img alt="low: 0" src="https://img.shields.io/badge/L-0-lightgrey"/> <img alt="unspecified: 1" src="https://img.shields.io/badge/U-1-lightgrey"/><strong>github.com/docker/docker</strong> <code>20.10.25+incompatible</code> (golang)</summary> <small><code>pkg:golang/github.com/docker/docker@20.10.25+incompatible</code></small><br/> <a href="https://scout.docker.com/v/CVE-2024-24557?s=github&n=docker&ns=github.com%2Fdocker&t=golang&vr=%3C24.0.9"><img alt="medium 6.9: CVE--2024--24557" src="https://img.shields.io/badge/CVE--2024--24557-lightgrey?label=medium%206.9&labelColor=fbb552"/></a> <i>Insufficient Verification of Data Authenticity</i> <table> <tr><td>Affected range</td><td><code><24.0.9</code></td></tr> <tr><td>Fixed version</td><td><code>24.0.9</code></td></tr> <tr><td>CVSS Score</td><td><code>6.9</code></td></tr> <tr><td>CVSS Vector</td><td><code>CVSS:3.1/AV:L/AC:H/PR:N/UI:R/S:C/C:L/I:H/A:L</code></td></tr> </table> <details><summary>Description</summary> <blockquote> The classic builder cache system is prone to cache poisoning if the image is built `FROM scratch`. Also, changes to some instructions (most important being `HEALTHCHECK` and `ONBUILD`) would not cause a cache miss. An attacker with the knowledge of the Dockerfile someone is using could poison their cache by making them pull a specially crafted image that would be considered as a valid cache candidate for some build steps. For example, an attacker could create an image that is considered as a valid cache candidate for: FROM scratch MAINTAINER Pawel when in fact the malicious image used as a cache would be an image built from a different Dockerfile. In the second case, the attacker could for example substitute a different `HEALTCHECK` command. ### Impact 23.0+ users are only affected if they explicitly opted out of Buildkit (`DOCKER_BUILDKIT=0` environment variable) or are using the `/build` API endpoint (which uses the classic builder by default). All users on versions older than 23.0 could be impacted. An example could be a CI with a shared cache, or just a regular Docker user pulling a malicious image due to misspelling/typosquatting. Image build API endpoint (`/build`) and `ImageBuild` function from `github.com/docker/docker/client` is also affected as it the uses classic builder by default. ### Patches Patches are included in Moby releases: - v25.0.2 - v24.0.9 - v23.0.10 ### Workarounds - Use `--no-cache` or use Buildkit if possible (`DOCKER_BUILDKIT=1`, it's default on 23.0+ assuming that the buildx plugin is installed). - Use `Version = types.BuilderBuildKit` or `NoCache = true` in `ImageBuildOptions` for `ImageBuild` call. </blockquote> </details> <a href="https://scout.docker.com/v/CVE-2024-29018?s=github&n=docker&ns=github.com%2Fdocker&t=golang&vr=%3C23.0.11"><img alt="medium 5.9: CVE--2024--29018" src="https://img.shields.io/badge/CVE--2024--29018-lightgrey?label=medium%205.9&labelColor=fbb552"/></a> <i>Incorrect Resource Transfer Between Spheres</i> <table> <tr><td>Affected range</td><td><code><23.0.11</code></td></tr> <tr><td>Fixed version</td><td><code>23.0.11</code></td></tr> <tr><td>CVSS Score</td><td><code>5.9</code></td></tr> <tr><td>CVSS Vector</td><td><code>CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N</code></td></tr> </table> <details><summary>Description</summary> <blockquote> Moby is an open source container framework originally developed by Docker Inc. as Docker. It is a key component of Docker Engine, Docker Desktop, and other distributions of container tooling or runtimes. As a batteries-included container runtime, Moby comes with a built-in networking implementation that enables communication between containers, and between containers and external resources. Moby's networking implementation allows for creating and using many networks, each with their own subnet and gateway. This feature is frequently referred to as custom networks, as each network can have a different driver, set of parameters, and thus behaviors. When creating a network, the `--internal` flag is used to designate a network as _internal_. The `internal` attribute in a docker-compose.yml file may also be used to mark a network _internal_, and other API clients may specify the `internal` parameter as well. When containers with networking are created, they are assigned unique network interfaces and IP addresses (typically from a non-routable [RFC 1918](https://datatracker.ietf.org/doc/html/rfc1918) subnet). The root network namespace (hereafter referred to as the 'host') serves as a router for non-internal networks, with a gateway IP that provides SNAT/DNAT to/from container IPs. Containers on an _internal_ network may communicate between each other, but are precluded from communicating with any networks the host has access to (LAN or WAN) as no default route is configured, and firewall rules are set up to drop all outgoing traffic. Communication with the gateway IP address (and thus appropriately configured host services) is possible, and the host may communicate with any container IP directly. In addition to configuring the Linux kernel's various networking features to enable container networking, `dockerd` directly provides some services to container networks. Principal among these is serving as a resolver, enabling service discovery (looking up other containers on the network by name), and resolution of names from an upstream resolver. When a DNS request for a name that does not correspond to a container is received, the request is forwarded to the configured upstream resolver (by default, the host's configured resolver). This request is made from the container network namespace: the level of access and routing of traffic is the same as if the request was made by the container itself. As a consequence of this design, containers solely attached to _internal_ network(s) will be unable to resolve names using the upstream resolver, as the container itself is unable to communicate with that nameserver. Only the names of containers also attached to the internal network are able to be resolved. Many systems will run a local forwarding DNS resolver, typically present on a loopback address (`127.0.0.0/8`), such as systemd-resolved or dnsmasq. Common loopback address examples include `127.0.0.1` or `127.0.0.53`. As the host and any containers have separate loopback devices, a consequence of the design described above is that containers are unable to resolve names from the host's configured resolver, as they cannot reach these addresses on the host loopback device. To bridge this gap, and to allow containers to properly resolve names even when a local forwarding resolver is used on a loopback address, `dockerd` will detect this scenario and instead forward DNS requests from the host/root network namespace. The loopback resolver will then forward the requests to its configured upstream resolvers, as expected. ## Impact Because `dockerd` will forward DNS requests to the host loopback device, bypassing the container network namespace's normal routing semantics entirely, _internal_ networks can unexpectedly forward DNS requests to an external nameserver. By registering a domain for which they control the authoritative nameservers, an attacker could arrange for a compromised container to exfiltrate data by encoding it in DNS queries that will eventually be answered by their nameservers. For example, if the domain `evil.example` was registered, the authoritative nameserver(s) for that domain could (eventually and indirectly) receive a request for `this-is-a-secret.evil.example`. Docker Desktop is not affected, as Docker Desktop always runs an internal resolver on a RFC 1918 address. ## Patches Moby releases 26.0.0-rc3, 25.0.5 (released) and 23.0.11 (to be released) are patched to prevent forwarding DNS requests from internal networks. ## Workarounds - Run containers intended to be solely attached to _internal_ networks with a custom upstream address (`--dns` argument to `docker run`, or API equivalent), which will force all upstream DNS queries to be resolved from the container network namespace. ## Background - yair zak originally reported this issue to the Docker security team. - PR <https://github.com/moby/moby/pull/46609> was opened in public to fix this issue, as it was not originally considered to have a security implication. - [The official documentation](https://docs.docker.com/network/drivers/ipvlan/#:~:text=If%20the%20parent,the%20network%20completely) claims that "the `--internal` flag that will completely isolate containers on a network from any communications external to that network," which necessitated this advisory and CVE. </blockquote> </details> <a href="https://scout.docker.com/v/GHSA-jq35-85cj-fj4p?s=github&n=docker&ns=github.com%2Fdocker&t=golang&vr=%3C20.10.27"><img alt="medium : GHSA--jq35--85cj--fj4p" src="https://img.shields.io/badge/GHSA--jq35--85cj--fj4p-lightgrey?label=medium%20&labelColor=fbb552"/></a> <table> <tr><td>Affected range</td><td><code><20.10.27</code></td></tr> <tr><td>Fixed version</td><td><code>24.0.7</code></td></tr></table> <details><summary>Description</summary> <blockquote> Intel's RAPL (Running Average Power Limit) feature, introduced by the Sandy Bridge microarchitecture, provides software insights into hardware energy consumption. To facilitate this, Intel introduced the powercap framework in Linux kernel 3.13, which reads values via relevant MSRs (model specific registers) and provides unprivileged userspace access via `sysfs`. As RAPL is an interface to access a hardware feature, it is only available when running on bare metal with the module compiled into the kernel. By 2019, it was realized that in some cases unprivileged access to RAPL readings could be exploited as a power-based side-channel against security features including AES-NI (potentially inside a SGX enclave) and KASLR (kernel address space layout randomization). Also known as the [PLATYPUS attack](https://platypusattack.com/), Intel assigned [CVE-2020-8694](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-8694) and [CVE-2020-8695](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-8695), and AMD assigned [CVE-2020-12912](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-12912). Several mitigations were applied; Intel reduced the sampling resolution via a microcode update, and the Linux kernel [prevents access by non-root users](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=949dd0104c496fa7c14991a23c03c62e44637e71) since 5.10. However, this kernel-based mitigation does not apply to many container-based scenarios: * Unless using user namespaces, root inside a container has the same level of privilege as root outside the container, but with a slightly more narrow view of the system * `sysfs` is mounted inside containers read-only; however only read access is needed to carry out this attack on an unpatched CPU While this is not a direct vulnerability in container runtimes, defense in depth and safe defaults are valuable and preferred, especially as this poses a risk to multi-tenant container environments running directly on affected hardware. This is provided by masking `/sys/devices/virtual/powercap` in the default mount configuration, and adding an additional set of rules to deny it in the default AppArmor profile. While `sysfs` is not the only way to read from the RAPL subsystem, other ways of accessing it require additional capabilities such as `CAP_SYS_RAWIO` which is not available to containers by default, or `perf` paranoia level less than 1, which is a non-default kernel tunable. ## References * https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-8694 * https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-8695 * https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-12912 * https://platypusattack.com/ * https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=949dd0104c496fa7c14991a23c03c62e44637e71 * https://web.eece.maine.edu/~vweaver/projects/rapl/ </blockquote> </details> <a href="https://scout.docker.com/v/GMS-2023-3981?s=gitlab&n=docker&ns=github.com%2Fdocker&t=golang&vr=%3C20.10.27"><img alt="unspecified : GMS--2023--3981" src="https://img.shields.io/badge/GMS--2023--3981-lightgrey?label=unspecified%20&labelColor=lightgrey"/></a> <i>OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities</i> <table> <tr><td>Affected range</td><td><code><20.10.27</code></td></tr> <tr><td>Fixed version</td><td><code>v24.0.7</code></td></tr></table> <details><summary>Description</summary> <blockquote> Intel's RAPL (Running Average Power Limit) feature, introduced by the Sandy Bridge microarchitecture, provides software insights into hardware energy consumption. To facilitate this, Intel introduced the powercap framework in Linux kernel 3.13, which reads values via relevant MSRs (model specific registers) and provides unprivileged userspace access via `sysfs`. </blockquote> </details> </details></td></tr> <tr><td valign="top"> <details><summary><img alt="critical: 0" src="https://img.shields.io/badge/C-0-lightgrey"/> <img alt="high: 0" src="https://img.shields.io/badge/H-0-lightgrey"/> <img alt="medium: 1" src="https://img.shields.io/badge/M-1-fbb552"/> <img alt="low: 1" src="https://img.shields.io/badge/L-1-fce1a9"/> <!-- unspecified: 0 --><strong>github.com/aws/aws-sdk-go</strong> <code>1.38.65</code> (golang)</summary> <small><code>pkg:golang/github.com/aws/aws-sdk-go@1.38.65</code></small><br/> <a href="https://scout.docker.com/v/CVE-2020-8911?s=golang&n=aws-sdk-go&ns=github.com%2Faws&t=golang&vr=%3E%3D0"><img alt="medium : CVE--2020--8911" src="https://img.shields.io/badge/CVE--2020--8911-lightgrey?label=medium%20&labelColor=fbb552"/></a> <table> <tr><td>Affected range</td><td><code>>=0</code></td></tr> <tr><td>Fixed version</td><td><strong>Not Fixed</strong></td></tr></table> <details><summary>Description</summary> <blockquote> The Go AWS S3 Crypto SDK contains vulnerabilities that can permit an attacker with write access to a bucket to decrypt files in that bucket. Files encrypted by the V1 EncryptionClient using either the AES-CBC content cipher or the KMS key wrap algorithm are vulnerable. Users should migrate to the V1 EncryptionClientV2 API, which will not create vulnerable files. Old files will remain vulnerable until re-encrypted with the new client. </blockquote> </details> <a href="https://scout.docker.com/v/CVE-2020-8912?s=golang&n=aws-sdk-go&ns=github.com%2Faws&t=golang&vr=%3E%3D0"><img alt="low : CVE--2020--8912" src="https://img.shields.io/badge/CVE--2020--8912-lightgrey?label=low%20&labelColor=fce1a9"/></a> <table> <tr><td>Affected range</td><td><code>>=0</code></td></tr> <tr><td>Fixed version</td><td><strong>Not Fixed</strong></td></tr></table> <details><summary>Description</summary> <blockquote> The Go AWS S3 Crypto SDK contains vulnerabilities that can permit an attacker with write access to a bucket to decrypt files in that bucket. Files encrypted by the V1 EncryptionClient using either the AES-CBC content cipher or the KMS key wrap algorithm are vulnerable. Users should migrate to the V1 EncryptionClientV2 API, which will not create vulnerable files. Old files will remain vulnerable until re-encrypted with the new client. </blockquote> </details> </details></td></tr> <tr><td valign="top"> <details><summary><img alt="critical: 0" src="https://img.shields.io/badge/C-0-lightgrey"/> <img alt="high: 0" src="https://img.shields.io/badge/H-0-lightgrey"/> <img alt="medium: 1" src="https://img.shields.io/badge/M-1-fbb552"/> <img alt="low: 0" src="https://img.shields.io/badge/L-0-lightgrey"/> <!-- unspecified: 0 --><strong>google.golang.org/protobuf</strong> <code>1.31.0</code> (golang)</summary> <small><code>pkg:golang/google.golang.org/protobuf@1.31.0</code></small><br/> <a href="https://scout.docker.com/v/CVE-2024-24786?s=github&n=protobuf&ns=google.golang.org&t=golang&vr=%3C1.33.0"><img alt="medium : CVE--2024--24786" src="https://img.shields.io/badge/CVE--2024--24786-lightgrey?label=medium%20&labelColor=fbb552"/></a> <i>Loop with Unreachable Exit Condition ('Infinite Loop')</i> <table> <tr><td>Affected range</td><td><code><1.33.0</code></td></tr> <tr><td>Fixed version</td><td><code>1.33.0</code></td></tr></table> <details><summary>Description</summary> <blockquote> The protojson.Unmarshal function can enter an infinite loop when unmarshaling certain forms of invalid JSON. This condition can occur when unmarshaling into a message which contains a google.protobuf.Any value, or when the UnmarshalOptions.DiscardUnknown option is set. </blockquote> </details> </details></td></tr> <tr><td valign="top"> <details><summary><img alt="critical: 0" src="https://img.shields.io/badge/C-0-lightgrey"/> <img alt="high: 0" src="https://img.shields.io/badge/H-0-lightgrey"/> <img alt="medium: 1" src="https://img.shields.io/badge/M-1-fbb552"/> <img alt="low: 0" src="https://img.shields.io/badge/L-0-lightgrey"/> <!-- unspecified: 0 --><strong>golang.org/x/net</strong> <code>0.19.0</code> (golang)</summary> <small><code>pkg:golang/golang.org/x/net@0.19.0</code></small><br/> <a href="https://scout.docker.com/v/CVE-2023-45288?s=github&n=net&ns=golang.org%2Fx&t=golang&vr=%3C0.23.0"><img alt="medium 5.3: CVE--2023--45288" src="https://img.shields.io/badge/CVE--2023--45288-lightgrey?label=medium%205.3&labelColor=fbb552"/></a> <i>Uncontrolled Resource Consumption</i> <table> <tr><td>Affected range</td><td><code><0.23.0</code></td></tr> <tr><td>Fixed version</td><td><code>0.23.0</code></td></tr> <tr><td>CVSS Score</td><td><code>5.3</code></td></tr> <tr><td>CVSS Vector</td><td><code>CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L</code></td></tr> </table> <details><summary>Description</summary> <blockquote> An attacker may cause an HTTP/2 endpoint to read arbitrary amounts of header data by sending an excessive number of CONTINUATION frames. Maintaining HPACK state requires parsing and processing all HEADERS and CONTINUATION frames on a connection. When a request's headers exceed MaxHeaderBytes, no memory is allocated to store the excess headers, but they are still parsed. This permits an attacker to cause an HTTP/2 endpoint to read arbitrary amounts of header data, all associated with a request which is going to be rejected. These headers can include Huffman-encoded data which is significantly more expensive for the receiver to decode than for an attacker to send. The fix sets a limit on the amount of excess header frames we will process before closing a connection. </blockquote> </details> </details></td></tr> <tr><td valign="top"> <details><summary><img alt="critical: 0" src="https://img.shields.io/badge/C-0-lightgrey"/> <img alt="high: 0" src="https://img.shields.io/badge/H-0-lightgrey"/> <img alt="medium: 1" src="https://img.shields.io/badge/M-1-fbb552"/> <img alt="low: 0" src="https://img.shields.io/badge/L-0-lightgrey"/> <!-- unspecified: 0 --><strong>golang.org/x/crypto</strong> <code>0.16.0</code> (golang)</summary> <small><code>pkg:golang/golang.org/x/crypto@0.16.0</code></small><br/> <a href="https://scout.docker.com/v/CVE-2023-48795?s=github&n=crypto&ns=golang.org%2Fx&t=golang&vr=%3C0.17.0"><img alt="medium 5.9: CVE--2023--48795" src="https://img.shields.io/badge/CVE--2023--48795-lightgrey?label=medium%205.9&labelColor=fbb552"/></a> <i>Insufficient Verification of Data Authenticity</i> <table> <tr><td>Affected range</td><td><code><0.17.0</code></td></tr> <tr><td>Fixed version</td><td><code>0.17.0</code></td></tr> <tr><td>CVSS Score</td><td><code>5.9</code></td></tr> <tr><td>CVSS Vector</td><td><code>CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N</code></td></tr> </table> <details><summary>Description</summary> <blockquote> ### Summary Terrapin is a prefix truncation attack targeting the SSH protocol. More precisely, Terrapin breaks the integrity of SSH's secure channel. By carefully adjusting the sequence numbers during the handshake, an attacker can remove an arbitrary amount of messages sent by the client or server at the beginning of the secure channel without the client or server noticing it. ### Mitigations To mitigate this protocol vulnerability, OpenSSH suggested a so-called "strict kex" which alters the SSH handshake to ensure a Man-in-the-Middle attacker cannot introduce unauthenticated messages as well as convey sequence number manipulation across handshakes. **Warning: To take effect, both the client and server must support this countermeasure.** As a stop-gap measure, peers may also (temporarily) disable the affected algorithms and use unaffected alternatives like AES-GCM instead until patches are available. ### Details The SSH specifications of ChaCha20-Poly1305 (chacha20-poly1305@openssh.com) and Encrypt-then-MAC (*-etm@openssh.com MACs) are vulnerable against an arbitrary prefix truncation attack (a.k.a. Terrapin attack). This allows for an extension negotiation downgrade by stripping the SSH_MSG_EXT_INFO sent after the first message after SSH_MSG_NEWKEYS, downgrading security, and disabling attack countermeasures in some versions of OpenSSH. When targeting Encrypt-then-MAC, this attack requires the use of a CBC cipher to be practically exploitable due to the internal workings of the cipher mode. Additionally, this novel attack technique can be used to exploit previously unexploitable implementation flaws in a Man-in-the-Middle scenario. The attack works by an attacker injecting an arbitrary number of SSH_MSG_IGNORE messages during the initial key exchange and consequently removing the same number of messages just after the initial key exchange has concluded. This is possible due to missing authentication of the excess SSH_MSG_IGNORE messages and the fact that the implicit sequence numbers used within the SSH protocol are only checked after the initial key exchange. In the case of ChaCha20-Poly1305, the attack is guaranteed to work on every connection as this cipher does not maintain an internal state other than the message's sequence number. In the case of Encrypt-Then-MAC, practical exploitation requires the use of a CBC cipher; while theoretical integrity is broken for all ciphers when using this mode, message processing will fail at the application layer for CTR and stream ciphers. For more details see [https://terrapin-attack.com](https://terrapin-attack.com). ### Impact This attack targets the specification of ChaCha20-Poly1305 (chacha20-poly1305@openssh.com) and Encrypt-then-MAC (*-etm@openssh.com), which are widely adopted by well-known SSH implementations and can be considered de-facto standard. These algorithms can be practically exploited; however, in the case of Encrypt-Then-MAC, we additionally require the use of a CBC cipher. As a consequence, this attack works against all well-behaving SSH implementations supporting either of those algorithms and can be used to downgrade (but not fully strip) connection security in case SSH extension negotiation (RFC8308) is supported. The attack may also enable attackers to exploit certain implementation flaws in a man-in-the-middle (MitM) scenario. </blockquote> </details> </details></td></tr> <tr><td valign="top"> <details><summary><img alt="critical: 0" src="https://img.shields.io/badge/C-0-lightgrey"/> <img alt="high: 0" src="https://img.shields.io/badge/H-0-lightgrey"/> <img alt="medium: 1" src="https://img.shields.io/badge/M-1-fbb552"/> <img alt="low: 0" src="https://img.shields.io/badge/L-0-lightgrey"/> <!-- unspecified: 0 --><strong>k8s.io/apiserver</strong> <code>0.28.6</code> (golang)</summary> <small><code>pkg:golang/k8s.io/apiserver@0.28.6</code></small><br/> <a href="https://scout.docker.com/v/CVE-2020-8552?s=gitlab&n=apiserver&ns=k8s.io&t=golang&vr=%3C1.15.10"><img alt="medium 4.3: CVE--2020--8552" src="https://img.shields.io/badge/CVE--2020--8552-lightgrey?label=medium%204.3&labelColor=fbb552"/></a> <i>OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities</i> <table> <tr><td>Affected range</td><td><code><1.15.10</code></td></tr> <tr><td>Fixed version</td><td><code>1.15.10, 1.16.7, 1.17.3</code></td></tr> <tr><td>CVSS Score</td><td><code>4.3</code></td></tr> <tr><td>CVSS Vector</td><td><code>CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L</code></td></tr> </table> <details><summary>Description</summary> <blockquote> The Kubernetes API server component has been found to be vulnerable to a denial of service attack via successful API requests. </blockquote> </details> </details></td></tr> <tr><td valign="top"> <details><summary><img alt="critical: 0" src="https://img.shields.io/badge/C-0-lightgrey"/> <img alt="high: 0" src="https://img.shields.io/badge/H-0-lightgrey"/> <img alt="medium: 0" src="https://img.shields.io/badge/M-0-lightgrey"/> <img alt="low: 1" src="https://img.shields.io/badge/L-1-fce1a9"/> <!-- unspecified: 0 --><strong>k8s.io/kubernetes</strong> <code>1.28.6</code> (golang)</summary> <small><code>pkg:golang/k8s.io/kubernetes@1.28.6</code></small><br/> <a href="https://scout.docker.com/v/CVE-2024-3177?s=github&n=kubernetes&ns=k8s.io&t=golang&vr=%3E%3D1.28.0%2C%3C%3D1.28.8"><img alt="low 2.7: CVE--2024--3177" src="https://img.shields.io/badge/CVE--2024--3177-lightgrey?label=low%202.7&labelColor=fce1a9"/></a> <i>Improper Input Validation</i> <table> <tr><td>Affected range</td><td><code>>=1.28.0<br/><=1.28.8</code></td></tr> <tr><td>Fixed version</td><td><code>1.28.9</code></td></tr> <tr><td>CVSS Score</td><td><code>2.7</code></td></tr> <tr><td>CVSS Vector</td><td><code>CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:N</code></td></tr> </table> <details><summary>Description</summary> <blockquote> A security issue was discovered in Kubernetes where users may be able to launch containers that bypass the mountable secrets policy enforced by the ServiceAccount admission plugin when using containers, init containers, and ephemeral containers with the envFrom field populated. The policy ensures pods running with a service account may only reference secrets specified in the service account’s secrets field. Kubernetes clusters are only affected if the ServiceAccount admission plugin and the kubernetes.io/enforce-mountable-secrets annotation are used together with containers, init containers, and ephemeral containers with the envFrom field populated. </blockquote> </details> </details></td></tr> <tr><td valign="top"> <details><summary><img alt="critical: 0" src="https://img.shields.io/badge/C-0-lightgrey"/> <img alt="high: 0" src="https://img.shields.io/badge/H-0-lightgrey"/> <img alt="medium: 0" src="https://img.shields.io/badge/M-0-lightgrey"/> <img alt="low: 0" src="https://img.shields.io/badge/L-0-lightgrey"/> <img alt="unspecified: 8" src="https://img.shields.io/badge/U-8-lightgrey"/><strong>stdlib</strong> <code>1.20.13</code> (golang)</summary> <small><code>pkg:golang/stdlib@1.20.13</code></small><br/> <a href="https://scout.docker.com/v/CVE-2024-24790?s=golang&n=stdlib&t=golang&vr=%3C1.21.11"><img alt="unspecified : CVE--2024--24790" src="https://img.shields.io/badge/CVE--2024--24790-lightgrey?label=unspecified%20&labelColor=lightgrey"/></a> <table> <tr><td>Affected range</td><td><code><1.21.11</code></td></tr> <tr><td>Fixed version</td><td><code>1.21.11</code></td></tr></table> <details><summary>Description</summary> <blockquote> The various Is methods (IsPrivate, IsLoopback, etc) did not work as expected for IPv4-mapped IPv6 addresses, returning false for addresses which would return true in their traditional IPv4 forms. </blockquote> </details> <a href="https://scout.docker.com/v/CVE-2024-24789?s=golang&n=stdlib&t=golang&vr=%3C1.21.11"><img alt="unspecified : CVE--2024--24789" src="https://img.shields.io/badge/CVE--2024--24789-lightgrey?label=unspecified%20&labelColor=lightgrey"/></a> <table> <tr><td>Affected range</td><td><code><1.21.11</code></td></tr> <tr><td>Fixed version</td><td><code>1.21.11</code></td></tr></table> <details><summary>Description</summary> <blockquote> The archive/zip package's handling of certain types of invalid zip files differs from the behavior of most zip implementations. This misalignment could be exploited to create an zip file with contents that vary depending on the implementation reading the file. The archive/zip package now rejects files containing these errors. </blockquote> </details> <a href="https://scout.docker.com/v/CVE-2024-24785?s=golang&n=stdlib&t=golang&vr=%3C1.21.8"><img alt="unspecified : CVE--2024--24785" src="https://img.shields.io/badge/CVE--2024--24785-lightgrey?label=unspecified%20&labelColor=lightgrey"/></a> <table> <tr><td>Affected range</td><td><code><1.21.8</code></td></tr> <tr><td>Fixed version</td><td><code>1.21.8</code></td></tr></table> <details><summary>Description</summary> <blockquote> If errors returned from MarshalJSON methods contain user controlled data, they may be used to break the contextual auto-escaping behavior of the html/template package, allowing for subsequent actions to inject unexpected content into templates. </blockquote> </details> <a href="https://scout.docker.com/v/CVE-2024-24784?s=golang&n=stdlib&t=golang&vr=%3C1.21.8"><img alt="unspecified : CVE--2024--24784" src="https://img.shields.io/badge/CVE--2024--24784-lightgrey?label=unspecified%20&labelColor=lightgrey"/></a> <table> <tr><td>Affected range</td><td><code><1.21.8</code></td></tr> <tr><td>Fixed version</td><td><code>1.21.8</code></td></tr></table> <details><summary>Description</summary> <blockquote> The ParseAddressList function incorrectly handles comments (text within parentheses) within display names. Since this is a misalignment with conforming address parsers, it can result in different trust decisions being made by programs using different parsers. </blockquote> </details> <a href="https://scout.docker.com/v/CVE-2024-24783?s=golang&n=stdlib&t=golang&vr=%3C1.21.8"><img alt="unspecified : CVE--2024--24783" src="https://img.shields.io/badge/CVE--2024--24783-lightgrey?label=unspecified%20&labelColor=lightgrey"/></a> <table> <tr><td>Affected range</td><td><code><1.21.8</code></td></tr> <tr><td>Fixed version</td><td><code>1.21.8</code></td></tr></table> <details><summary>Description</summary> <blockquote> Verifying a certificate chain which contains a certificate with an unknown public key algorithm will cause Certificate.Verify to panic. This affects all crypto/tls clients, and servers that set Config.ClientAuth to VerifyClientCertIfGiven or RequireAndVerifyClientCert. The default behavior is for TLS servers to not verify client certificates. </blockquote> </details> <a href="https://scout.docker.com/v/CVE-2023-45290?s=golang&n=stdlib&t=golang&vr=%3C1.21.8"><img alt="unspecified : CVE--2023--45290" src="https://img.shields.io/badge/CVE--2023--45290-lightgrey?label=unspecified%20&labelColor=lightgrey"/></a> <table> <tr><td>Affected range</td><td><code><1.21.8</code></td></tr> <tr><td>Fixed version</td><td><code>1.21.8</code></td></tr></table> <details><summary>Description</summary> <blockquote> When parsing a multipart form (either explicitly with Request.ParseMultipartForm or implicitly with Request.FormValue, Request.PostFormValue, or Request.FormFile), limits on the total size of the parsed form were not applied to the memory consumed while reading a single form line. This permits a maliciously crafted input containing very long lines to cause allocation of arbitrarily large amounts of memory, potentially leading to memory exhaustion. With fix, the ParseMultipartForm function now correctly limits the maximum size of form lines. </blockquote> </details> <a href="https://scout.docker.com/v/CVE-2023-45289?s=golang&n=stdlib&t=golang&vr=%3C1.21.8"><img alt="unspecified : CVE--2023--45289" src="https://img.shields.io/badge/CVE--2023--45289-lightgrey?label=unspecified%20&labelColor=lightgrey"/></a> <table> <tr><td>Affected range</td><td><code><1.21.8</code></td></tr> <tr><td>Fixed version</td><td><code>1.21.8</code></td></tr></table> <details><summary>Description</summary> <blockquote> When following an HTTP redirect to a domain which is not a subdomain match or exact match of the initial domain, an http.Client does not forward sensitive headers such as "Authorization" or "Cookie". For example, a redirect from foo.com to www.foo.com will forward the Authorization header, but a redirect to bar.com will not. A maliciously crafted HTTP redirect could cause sensitive headers to be unexpectedly forwarded. </blockquote> </details> <a href="https://scout.docker.com/v/CVE-2023-45288?s=golang&n=stdlib&t=golang&vr=%3C1.21.9"><img alt="unspecified : CVE--2023--45288" src="https://img.shields.io/badge/CVE--2023--45288-lightgrey?label=unspecified%20&labelColor=lightgrey"/></a> <table> <tr><td>Affected range</td><td><code><1.21.9</code></td></tr> <tr><td>Fixed version</td><td><code>1.21.9</code></td></tr></table> <details><summary>Description</summary> <blockquote> An attacker may cause an HTTP/2 endpoint to read arbitrary amounts of header data by sending an excessive number of CONTINUATION frames. Maintaining HPACK state requires parsing and processing all HEADERS and CONTINUATION frames on a connection. When a request's headers exceed MaxHeaderBytes, no memory is allocated to store the excess headers, but they are still parsed. This permits an attacker to cause an HTTP/2 endpoint to read arbitrary amounts of header data, all associated with a request which is going to be rejected. These headers can include Huffman-encoded data which is significantly more expensive for the receiver to decode than for an attacker to send. The fix sets a limit on the amount of excess header frames we will process before closing a connection. </blockquote> </details> </details></td></tr> </table>

[github-actions]

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

[github-actions]

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