An issue was discovered in JasPer 2.0.14. There is an access violation in the function jasimagereadcmpt in libjasper/base/jasimage.c, leading to a denial of service.

An issue was discovered in JasPer 2.0.14. There is a NULL pointer dereference in the function jp2decode in libjasper/jp2/jp2dec.c, leading to a denial of service.

A UNIX Symbolic Link (Symlink) Following vulnerability in logrotate config in the exim package allowed privilege escalation from mail user/group to root.This issue affects Tumbleweed: from ? before 4.98.2-lp156.248.1.

A user who can supply bundle content to a repository referenced by a GitRepo resource, for example through Git push access, or through permission to create or modify a GitRepo, can cause SUSE Rancher Fleet to read files from the filesystem of the environment that processes the bundle and include their contents in the generated Bundle resource. This can expose configuration or credential material that the user has no Kubernetes RBAC permission to read, including Helm registry credentials made available to the bundle-processing job when per-path Helm credentials are configured. This affects Fleet 0.16 before 0.16.2, 0.15 before 0.15.7, 0.14 before 0.14.11, 0.13 before 0.13.16, 0.12 before 0.12.20 and potentially older unsupported versions.

A vulnerability was discovered in Fleet's Git webhook receiver (the gitjob webhook service). When a webhook secret is not configured, incoming webhook requests are accepted without verification, and processing a request can change the spec.pollingInterval field of a matching GitRepo resource in any namespace. A caller with network access to the webhook service and no Kubernetes credentials can therefore alter GitRepo configuration outside

the namespaces they are authorized for.  This only affects SUSE Rancher Fleet 0.16 before 0.16.2, older versions are not affected.

A privilege mismatch was found in Fleet. When a bundle requested namespace labels or annotations through the namespaceLabels and namespaceAnnotations options, the resulting namespace metadata update was not subject to the same authorization as the rest of the bundle's deployment. As a result, a bundle could change labels and annotations on a target namespace even when the identity it was pinned to was not authorized to modify that namespace.

This affected SUSE Rancher Fleet 0.16 before 0.16.2, 0.15 before 0.15.7, 0.14 before 0.14.11, 0.13 before 0.13.16 and potentially older versions.

A security vulnerability was discovered in Fleet's Helm template preprocessing where templates evaluated by the Fleet controller could reach network resources outside the management cluster. A user who can supply bundle content to a repository referenced by a GitRepo resource can cause the Fleet controller to: - Disclose cluster metadata available to the templating context. - Reveal information about hosts reachable from the controller's network position. Because the disclosure channel is name resolution, it may remain effective in environments where outbound traffic is otherwise restricted. The disclosed information is limited to values exposed to the Fleet templating context and to name resolution results. Integrity and availability of managed clusters are not affected.

This issue affects Fleet: from 0.12.0 before 0.12.19, from 0.13.0 before 0.13.15, from 0.14.0 before 0.14.10, from 0.15.0 before 0.15.6, and from 0.16.0 before 0.16.1.

Last updated 15 January 2025

Last updated 29 November 2024

A new exploitation technique called key reinstallation attacks used to break Wi-Fi handshakes that negotiate session keys was discovered. These attacks target the Wi-Fi/WPA2 standard. An adversary can trick a client or Access Point (AP) into reinstalling an already-in use pairwise key in 4-way handshake. While reinstalling the already in-use key, the associated packet number (sometimes also called nonce) and receive replay counter is reset. This causes nonce reuse, voiding any security the underlying encryption protocol is supposed to provide. For example, it allows decryption or injection of frames, and enables an attacker to replay frames.

The rancher-extension-stackstate extension in SUSE Observability exposes service tokens in plain configuration or insecure locations rather than managing them securely. An attacker with minimal access could obtain the token to gain unauthorized access or escalate privileges within the observability environment.

The default configuration of Apache (httpd.conf) on SuSE 6.4 includes an alias for the /usr/doc directory, which allows remote attackers to read package documentation and obtain system configuration information via an HTTP request for the /doc/packages URL.

A flaw was found in Rancher Manager. The /v3/users update path did not enforce immutability of a User resource's username and principalIds fields. A user holding the update verb on users.management.cattle.io could inject a foreign identity provider principal into any account, so that the next login by the owner of that principal was bound to the victim's account and inherited its role bindings.

This issue affects Rancher: before 2.15.1.

A flaw was found in rsync. It could allow a server to enumerate the contents of an arbitrary file from the client's machine. This issue occurs when files are being copied from a client to a server. During this process, the rsync server will send checksums of local data to the client to compare with in order to determine what data needs to be sent to the server. By sending specially constructed checksum values for arbitrary files, an attacker may be able to reconstruct the data of those files byte-by-byte based on the responses from the client.

Impact A vulnerability has been identified in Fleet when the helmRepoURLRegex field isn't set on a GitRepo resource. Fleet's bundle reader forwards Helm authentication credentials (BasicAuth) to any URL specified in the helm.repo field of a fleet.yaml file.

An attacker with git push access to a Fleet-monitored repository can exploit this behavior by specifying a malicious URL in helm.repo. This causes the Fleet controller to send the configured Helm repository credentials to the attacker’s server.

As a result, the attacker can capture the username and password that an administrator configured to access a private Helm chart repository. However, the response body from the attacker's server isn't included in the error message (this behavior was fixed in Fleet v0.13.3 and later), which prevents additional internal data from leaking through the status condition.

The final severity of this vulnerability depends on the specific permissions of the leaked credentials.

Fleet recommends you to: 1. Review your system for potentially leaked credentials. 2. Replace any credentials that might be compromised.

Please consult the associated MITRE ATT&CK - Technique - Stored Data Manipulation and MITRE ATT&CK - Technique - Steal Application Access Token for further information about this category of attack.

Patches To resolve this vulnerability, upgrade to a patched version of Fleet. The patched version of Fleet now requires you to set the helmRepoURLRegex field on the GitRepo. If the helmRepoURLRegex is empty or missing, Fleet won’t send credentials, regardless of the URL specified in fleet.yaml. When you upgrade, a Helm pre-upgrade job automatically migrates existing GitRepo resources that have helmSecretName or helmSecretNameForPaths configured but lack a helmRepoURLRegex. The migration job performs the following actions:

The job extracts the scheme and host from the Helm repository URLs already stored in the resource's Bundles. For example, a GitRepo with Bundles referencing https://charts.example.com/stable receives helmRepoURLRegex: "^https://charts\.example\.com/". This limits credential forwarding to the origins already in use before the upgrade. Migrated resources are annotated with fleet.cattle.io/helm-regex-auto-migrated: "true" so you can easily audit them.

If no Bundles with Helm repository URLs exist during the migration (for example, if the GitRepo has never successfully synced), helmRepoURLRegex remains empty and credentials aren't forwarded. You must set this field manually before Fleet will send credentials.

The migration job runs only once per installation and records its status in a ConfigMap named fleet-helm-url-regex-migrated in the Fleet system namespace. Any GitRepo resources you create after the upgrade require an explicit helmRepoURLRegex to forward credentials.

Patched versions of Fleet include releases v0.15.2, v0.14.6, 0.13.11, and v0.12.15.

Workarounds If you cannot immediately upgrade to a patched version, use the following methods to mitigate the risk and audit your environment. Set helmRepoURLRegex on all GitRepo resources that use helmSecretName. Ensure the regular expression matches only your legitimate Helm repository URL.

Example configuration: yaml apiVersion: fleet.cattle.io/v1alpha1 kind: GitRepo metadata: name: my-app namespace: fleet-local spec: repo: https://git.example.com/org/my-app.git helmSecretName: helm-creds helmRepoURLRegex: "^https://charts\\.example\\.com/."

After upgrading to a patched version, review all auto-migrated GitRepo resources by running the following command:

kubectl get gitrepo -A -o json | \ jq -r '.items[] | select(.metadata.annotations["fleet.cattle.io/helm-regex-auto-migrated"] == "true") | "\(.metadata.namespace)/\(.metadata.name): \(.spec.helmRepoURLRegex)"'

Verify that the auto-derived regular expression matches only your intended Helm repository origins. If a regular expression is broader than necessary, replace it with a more specific pattern.

Credits

This security issue was reported by the following collaborators according to our responsible disclosure policy:

- Radisauskas Arnoldas from NATO and the NATO Cyber Security Centre (NCSC). - FluentLogic's security team.

References If you have any questions or comments about this advisory: - Reach out to the SUSE Rancher Security team for security related inquiries. - Open an issue in the Rancher repository. - Verify with our support matrix and product support lifecycle.

Relax-and-Recover (aka ReaR) through 2.7 creates a world-readable initrd when using GRUBRESCUE=y. This allows local attackers to gain access to system secrets otherwise only readable by root.

DISPUTED An issue was discovered in the Linux kernel before 6.3.3. There is an out-of-bounds read in crc16 in lib/crc16.c when called from fs/ext4/super.c because ext4groupdesccsum does not properly check an offset. NOTE: this is disputed by third parties because the kernel is not intended to defend against attackers with the stated "When modifying the block device while it is mounted by the filesystem" access.

An Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') vulnerability in spacewalk/Uyuni of SUSE Linux Enterprise Module for SUSE Manager Server 4.2, SUSE Linux Enterprise Module for SUSE Manager Server 4.3, SUSE Manager Server 4.2 allows remote attackers to embed Javascript code via /rhn/audit/scap/Search.do This issue affects: SUSE Linux Enterprise Module for SUSE Manager Server 4.2 hub-xmlrpc-api-0.7-150300.3.9.2, inter-server-sync-0.2.4-150300.8.25.2, locale-formula-0.3-150300.3.3.2, py27-compat-salt-3000.3-150300.7.7.26.2, python-urlgrabber-3.10.2.1py23-150300.3.3.2, spacecmd-4.2.20-150300.4.30.2, spacewalk-backend-4.2.25-150300.4.32.4, spacewalk-client-tools-4.2.21-150300.4.27.3, spacewalk-java-4.2.43-150300.3.48.2, spacewalk-utils-4.2.18-150300.3.21.2, spacewalk-web-4.2.30-150300.3.30.3, susemanager-4.2.38-150300.3.44.3, susemanager-doc-indexes-4.2-150300.12.36.3, susemanager-docsen-4.2-150300.12.36.2, susemanager-schema-4.2.25-150300.3.30.3, susemanager-sls versions prior to 4.2.28. SUSE Linux Enterprise Module for SUSE Manager Server 4.3 spacewalk-java versions prior to 4.3.39. SUSE Manager Server 4.2 release-notes-susemanager versions prior to 4.2.10.

A Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') vulnerability in spacewalk/Uyuni of SUSE Linux Enterprise Module for SUSE Manager Server 4.2, SUSE Linux Enterprise Module for SUSE Manager Server 4.3, SUSE Manager Server 4.2 allows remote attackers to read files available to the user running the process, typically tomcat. This issue affects: SUSE Linux Enterprise Module for SUSE Manager Server 4.2 hub-xmlrpc-api-0.7-150300.3.9.2, inter-server-sync-0.2.4-150300.8.25.2, locale-formula-0.3-150300.3.3.2, py27-compat-salt-3000.3-150300.7.7.26.2, python-urlgrabber-3.10.2.1py23-150300.3.3.2, spacecmd-4.2.20-150300.4.30.2, spacewalk-backend-4.2.25-150300.4.32.4, spacewalk-client-tools-4.2.21-150300.4.27.3, spacewalk-java-4.2.43-150300.3.48.2, spacewalk-utils-4.2.18-150300.3.21.2, spacewalk-web-4.2.30-150300.3.30.3, susemanager-4.2.38-150300.3.44.3, susemanager-doc-indexes-4.2-150300.12.36.3, susemanager-docsen-4.2-150300.12.36.2, susemanager-schema-4.2.25-150300.3.30.3, susemanager-sls versions prior to 4.2.28. SUSE Linux Enterprise Module for SUSE Manager Server 4.3 spacewalk-java versions prior to 4.3.39. SUSE Manager Server 4.2 release-notes-susemanager versions prior to 4.2.10.

A Race Condition Enabling Link Following vulnerability in the cron job shipped with texlive-filesystem of SUSE Linux Enterprise Module for Desktop Applications 15-SP1, SUSE Linux Enterprise Software Development Kit 12-SP4, SUSE Linux Enterprise Software Development Kit 12-SP5; openSUSE Leap 15.1 allows local users in group mktex to delete arbitrary files on the system This issue affects: SUSE Linux Enterprise Module for Desktop Applications 15-SP1 texlive-filesystem versions prior to 2017.135-9.5.1. SUSE Linux Enterprise Software Development Kit 12-SP4 texlive-filesystem versions prior to 2013.74-16.5.1. SUSE Linux Enterprise Software Development Kit 12-SP5 texlive-filesystem versions prior to 2013.74-16.5.1. openSUSE Leap 15.1 texlive-filesystem versions prior to 2017.135-lp151.8.3.1.

Cacti 1.2.8 has stored XSS in datasources.php, colortemplatesitem.php, graphs.php, graphitems.php, lib/apiautomation.php, useradmin.php, and usergroupadmin.php, as demonstrated by the description parameter in datasources.php (a raw string from the database that is displayed by $header to trigger the XSS).

An inappropriate implementation flaw was found in the V8 component of the Chromium browser.

Upstream bug(s):

https://code.google.com/p/chromium/issues/detail?id=1052647

External References:

https://chromereleases.googleblog.com/2020/03/stable-channel-update-for-desktop18.html

An insufficient policy enforcement flaw was found in the CORS component of the Chromium browser.

Upstream bug(s):

https://code.google.com/p/chromium/issues/detail?id=1026546

External References:

https://chromereleases.googleblog.com/2020/02/stable-channel-update-for-desktop.html

An incorrect security ui flaw was found in the Omnibox component of the Chromium browser.

Upstream bug(s):

https://code.google.com/p/chromium/issues/detail?id=1006012

External References:

https://chromereleases.googleblog.com/2020/02/stable-channel-update-for-desktop.html

An inappropriate implementation flaw was found in the CORS component of the Chromium browser.

Upstream bug(s):

https://code.google.com/p/chromium/issues/detail?id=1038036

External References:

https://chromereleases.googleblog.com/2020/02/stable-channel-update-for-desktop.html

An incorrect security ui flaw was found in the sharing component of the Chromium browser.

Upstream bug(s):

https://code.google.com/p/chromium/issues/detail?id=1027408

External References:

https://chromereleases.googleblog.com/2020/02/stable-channel-update-for-desktop.html

An inappropriate implementation flaw was found in the Skia component of the Chromium browser.

Upstream bug(s):

https://code.google.com/p/chromium/issues/detail?id=1035271

External References:

https://chromereleases.googleblog.com/2020/02/stable-channel-update-for-desktop.html

An insufficient policy enforcement flaw was found in the extensions component of the Chromium browser.

Upstream bug(s):

https://code.google.com/p/chromium/issues/detail?id=1030411

External References:

https://chromereleases.googleblog.com/2020/02/stable-channel-update-for-desktop.html

An insufficient policy enforcement flaw was found in the Blink component of the Chromium browser.

Upstream bug(s):

https://code.google.com/p/chromium/issues/detail?id=1035058

External References:

https://chromereleases.googleblog.com/2020/02/stable-channel-update-for-desktop.html

An insufficient policy enforcement flaw was found in the Blink component of the Chromium browser.

Upstream bug(s):

https://code.google.com/p/chromium/issues/detail?id=1014371

External References:

https://chromereleases.googleblog.com/2020/02/stable-channel-update-for-desktop.html