chore(deps): update dependency grafana/agent to v0.43.0

[uniget-bot]

This PR contains the following updates:

Package	Update	Change
grafana/agent	minor	0.42.0 -> 0.43.0

---

Warning

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

---

Release Notes

grafana/agent (grafana/agent)

v0.43.0

Compare Source

Bugfixes

• Fix a memory leak which would occur any time loki.process had its configuration reloaded. (@​ptodev)

• Fix a bug where custom components would not shadow the stdlib. If you have a module whose name conflicts with an stdlib function
  and if you use this exact function in your config, then you will need to rename your module. (@​wildum)

• Fix an issue where nested import.git config blocks could conflict if they had the same labels. (@​wildum)

• Fix an issue where loki.source.docker stops collecting logs after a container restart. (@​wildum)

Other changes

• Change the Docker base image for Linux containers to ubuntu:noble. (@​amontalban)

---

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/grafana-agent:0.43.0

📦 Image Reference ghcr.io/uniget-org/tools/grafana-agent:0.43.0

digest	sha256:55601bc0171d7d6102f81d4d64bcf00a02347979f217ebe4c387fa5e7823156d
vulnerabilities
platform	linux/amd64
size	123 MB
packages	612

github.com/docker/docker 24.0.9+incompatible (golang) pkg:golang/github.com/docker/[email protected]+incompatible Partial String Comparison Affected range >=24.0.0 <25.0.6 Fixed version 26.1.4 CVSS Score 9.9 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H Description A security vulnerability has been detected in certain versions of Docker Engine, which could allow an attacker to bypass authorization plugins (AuthZ) under specific circumstances. The base likelihood of this being exploited is low. This advisory outlines the issue, identifies the affected versions, and provides remediation steps for impacted users. Impact Using a specially-crafted API request, an Engine API client could make the daemon forward the request or response to an authorization plugin without the body. In certain circumstances, the authorization plugin may allow a request which it would have otherwise denied if the body had been forwarded to it. A security issue was discovered In 2018, where an attacker could bypass AuthZ plugins using a specially crafted API request. This could lead to unauthorized actions, including privilege escalation. Although this issue was fixed in Docker Engine v18.09.1 in January 2019, the fix was not carried forward to later major versions, resulting in a regression. Anyone who depends on authorization plugins that introspect the request and/or response body to make access control decisions is potentially impacted. Docker EE v19.03.x and all versions of Mirantis Container Runtime are not vulnerable. Vulnerability details AuthZ bypass and privilege escalation: An attacker could exploit a bypass using an API request with Content-Length set to 0, causing the Docker daemon to forward the request without the body to the AuthZ plugin, which might approve the request incorrectly. Initial fix: The issue was fixed in Docker Engine v18.09.1 January 2019.. Regression: The fix was not included in Docker Engine v19.03 or newer versions. This was identified in April 2024 and patches were released for the affected versions on July 23, 2024. The issue was assigned CVE-2024-41110. Patches docker-ce v27.1.1 containes patches to fix the vulnerability. Patches have also been merged into the master, 19.0, 20.0, 23.0, 24.0, 25.0, 26.0, and 26.1 release branches. Remediation steps If you are running an affected version, update to the most recent patched version. Mitigation if unable to update immediately: Avoid using AuthZ plugins. Restrict access to the Docker API to trusted parties, following the principle of least privilege. References moby/moby@fc274cd moby/moby@a79fabb https://www.docker.com/blog/docker-security-advisory-docker-engine-authz-plugin/

stdlib 1.22.5 (golang) pkg:golang/[email protected] Affected range <1.22.7 Fixed version 1.22.7 Description Calling Parse on a "// +build" build tag line with deeply nested expressions can cause a panic due to stack exhaustion. Affected range <1.22.7 Fixed version 1.22.7 Description Calling Decoder.Decode on a message which contains deeply nested structures can cause a panic due to stack exhaustion. This is a follow-up to CVE-2022-30635. Affected range <1.22.7 Fixed version 1.22.7 Description Calling Decoder.Decode on a message which contains deeply nested structures can cause a panic due to stack exhaustion. This is a follow-up to CVE-2022-30635. Affected range <1.22.7 Fixed version 1.22.7 Description Calling any of the Parse functions on Go source code which contains deeply nested literals can cause a panic due to stack exhaustion.

github.com/opencontainers/runc 1.1.12 (golang) pkg:golang/github.com/opencontainers/[email protected] 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. Race Condition Enabling Link Following Affected range <1.1.14 Fixed version 1.1.14 CVSS Score 3.6 CVSS Vector CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:N/I:L/A:N 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. main patches: rootfs: consolidate mountpoint creation logic opencontainers/runc#4359 opencontainers/runc@63c2908 release-1.1 patches: opencontainers/runc@8781993 opencontainers/runc@f0b652e Credits Thanks to Rodrigo Campos Catelin (@rata) and Alban Crequy (@alban) from Microsoft for discovering and reporting this vulnerability.

github.com/aws/aws-sdk-go 1.50.27 (golang) pkg:golang/github.com/aws/[email protected] Affected range >=0 Fixed version Not Fixed Description 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. Affected range >=0 Fixed version Not Fixed Description 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.

github.com/open-telemetry/opentelemetry-collector-contrib/extension/bearertokenauthextension 0.96.0 (golang) pkg:golang/github.com/open-telemetry/opentelemetry-collector-contrib/extension/[email protected] Observable Timing Discrepancy Affected range >=0.80.0 <0.107.0 Fixed version 0.107.0 CVSS Score 6.5 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L Description Summary The bearertokenauth extension's server authenticator performs a simple, non-constant time string comparison of the received & configured bearer tokens. Details https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/9128a9258fe1fee36f198f97b1e3371fc7b77a93/extension/bearertokenauthextension/bearertokenauth.go#L189-L196 For background on the type of vulnerability, see https://ropesec.com/articles/timing-attacks/. Impact This impacts anyone using the bearertokenauth server authenticator. Malicious clients with network access to the collector may perform a timing attack against a collector with this authenticator to guess the configured token, by iteratively sending tokens and comparing the response time. This would allow an attacker to introduce fabricated or bad data into the collector's telemetry pipeline. Fix The observable timing vulnerability was fixed by @axw in v0.107.0 (PR open-telemetry/opentelemetry-collector-contrib#34516) by using constant-time comparison. Workarounds upgrade to v0.107.0 or above, or, if you're unable to upgrade at this time, don't expose the receiver using bearertokenauth to network segments accessible by potential attackers, or change the receiver to use a different authentication extension instead, or disable the receiver relying on bearertokenauth

github.com/go-resty/resty/v2 2.7.0 (golang) pkg:golang/github.com/go-resty/resty/[email protected] OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities Affected range <=v2.10.0 Fixed version Not Fixed CVSS Score 5.9 CVSS Vector CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N Description A race condition in go-resty can result in HTTP request body disclosure across requests. This condition can be triggered by calling sync.Pool.Put with the same *bytes.Buffer more than once, when request retries are enabled and a retry occurs. The call to sync.Pool.Get will then return a bytes.Buffer that hasn't had bytes.Buffer.Reset called on it. This dirty buffer will contain the HTTP request body from an unrelated request, and go-resty will append the current HTTP request body to it, sending two bodies in one request. The sync.Pool in question is defined at package level scope, so a completely unrelated server could receive the request body.

github.com/grafana/loki 1.6.2-0.20240510183741-cef4c2826b4b (golang) pkg:golang/github.com/grafana/[email protected] Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') Affected range <2.3.0 Fixed version 2.3.0 CVSS Score 5.3 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N Description An issue was discovered in Grafana Loki through 2.2.1. The header value X-Scope-OrgID is used to construct file paths for rules files, and if crafted to conduct directory traversal such as ae ../../sensitive/path/in/deployment pathname, then Loki will attempt to parse a rules file at that location and include some of the contents in the error message.

[github-actions]

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

[github-actions]

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