See how suse compares to other vendors in security performance
crypto: algifaead - Revert to operating out-of-place
A security regression (CVE-2006-5051) was discovered in OpenSSH's server (sshd). There is a race condition which can lead sshd to handle some signals in an unsafe manner. An unauthenticated, remote attacker may be able to trigger it by failing to authenticate within a set time period.
A flaw was found in rsync which could be triggered when rsync compares file checksums. This flaw allows an attacker to manipulate the checksum length (s2length) to cause a comparison between a checksum and uninitialized memory and leak one byte of uninitialized stack data at a time.
A Local Privilege Escalation vulnerability (from any user to root) was found in polkit's pkexec, a SUID-root program that is installed by default on every major Linux distribution.
A flaw was found in Node.js versions before 6.15.0, 8.14.0, 10.14.0 and 11.3.0. A Slowloris HTTP Denial of Service. An attacker can cause a Denial of Service (DoS) by sending headers very slowly keeping HTTP or HTTPS connections and associated resources alive for a long period of time.
References: https://nodejs.org/en/blog/vulnerability/november-2018-security-releases/
A flaw was found in Node.js before 6.15.0 and 8.14.0. An HTTP request splitting. If Node.js can be convinced to use unsanitized user-provided Unicode data for the path option of an HTTP request, then data can be provided which will trigger a second, unexpected, and user-defined HTTP request to made to the same server.
References: https://nodejs.org/en/blog/vulnerability/november-2018-security-releases/
Buffer overflow in ncurses 5.0, and the ncurses4 compatibility package as used in Red Hat Linux, allows local users to gain privileges, related to "routines for moving the physical cursor and scrolling."
Impact A vulnerability has been identified in Fleet when the webhook endpoint is configured without a secret; an attacker can forge webhook requests. The attacker doesn't need to know the specific repository or path configured in the GitRepo resource to make Fleet process these requests.
An attacker can exploit this vulnerability to cause the following impacts: 1. Trigger continuous repository re-cloning, which increases network traffic and can deplete resources on the management cluster. 2. Downgrade running services to any historical revision available in the remote Git repository. This risk applies if the attacker has read access to the target Git repository and knows its configured path.
Please consult the associated MITRE ATT&CK - Technique - T1499.004: Endpoint Denial of Service for further information about this category of attack.
Patches To resolve this vulnerability, upgrade Fleet to a patched version. This upgrade version escapes the URL and path to the remote repository received from webhooks, which prevents regular expressions from being used as a replacement for the URL and path.
Patched versions of Fleet include releases v0.15.2, v0.14.6, 0.13.11, and v0.12.15.
Workarounds If you can't upgrade to a fixed version, please make sure to only enable webhooks with a shared secret.
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).
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.
A Missing Authentication for Critical Function vulnerability in spacewalk-java of SUSE Manager Server 4.1, SUSE Manager Server 4.2 allows remote attackers to easily exhaust available disk resources leading to DoS. This issue affects: SUSE Manager Server 4.1 spacewalk-java versions prior to 4.1.46. SUSE Manager Server 4.2 spacewalk-java versions prior to 4.2.37.
A information disclosure when DEBUG loglevel is set in SUSE Rancher AI Agent 1.0 before 1.0.2 could leak API keys or LLM response text with potential sensitive data into logfiles, allowing local attackers to misuse respective gained data or credentials.
Impact A vulnerability has been identified within Rancher Manager in the GitHub App authentication provider. When evaluating permissions, the provider incorrectly expands user team memberships to include all teams within the associated GitHub organization, rather than restricting access to the specific teams to which the user actually belongs.
Specifically, when a user authenticates via the GitHub App provider, Rancher's team membership evaluation logic incorrectly handles cached data. Instead of checking the user-specific list, the evaluation logic iterates over all teams defined within the entire GitHub organization. The authentication provider should consult the correctly cached, per-user membership list to assign the user's specific group permissions. Consequently, any authenticated user who belongs to at least one team in a GitHub organization is mistakenly granted group principals for every team within that entire organization during authentication and authorization checks.
This issue allows a malicious user who is a member of a low-privilege team within a GitHub organization to gain unauthorized access to or permissions for any other team in that organization. If those other teams are bound to Rancher login allowlists or RBAC roles (cluster-level, project-level, or global), the attacker can pass access checks that should otherwise fail, inheriting permissions they were never granted.
Exploitation of this vulnerability requires the following conditions to be met: - The GitHub App authentication provider must be enabled and configured for the target GitHub organization. - The attacker must possess a valid GitHub account with membership in at least one team within that target organization. - A separate team within the same GitHub organization must be explicitly mapped to Rancher RBAC roles or specified within Rancher's login allowlist (allowedPrincipalIds).
Please consult the associated MITRE ATT&CK - Technique - Valid Accounts for further information about this category of attack.
Patches This fix corrects the team listing logic to iterate only the teams stored in the per-user membership cache and includes a one-time startup migration that marks all affected User resources for refresh, forcing Rancher to rebuild group principals using the now-corrected logic.
Patched versions of Rancher include releases v2.14.2 and v2.13.6.
Workarounds If upgrading to a patched version immediately is not feasible, users are encouraged to consider these temporary mitigations: - Disable GitHub App authentication provider and switch to an alternative authentication provider (GitHub OAuth). - Remove or restrict team-based group principals from allowed principalIds. - Audit and temporarily remove RBAC bindings (GlobalRoleBindings, ClusterRoleTemplateBindings, ProjectRoleTemplateBindings) that reference GitHub App team principals until the patch is applied. - Disable provider refresh and clean up inflated group membership for users (manually or by writing a script).
These workarounds reduce the attack surface but do not eliminate the vulnerability. Existing user sessions and cached principals remain inflated until a provider refresh occurs. Upgrading to a patched version is strongly recommended.
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.
A Local Privilege Escalation (LPE) vulnerability has been discovered in pam-config within Linux Pluggable Authentication Modules (PAM). This flaw allows an unprivileged local attacker (for example, a user logged in via SSH) to obtain the elevated privileges normally reserved for a physically present, "allowactive" user. The highest risk is that the attacker can then perform all allowactive yes Polkit actions, which are typically restricted to console users, potentially gaining unauthorized control over system configurations, services, or other sensitive operations.
A path traversal vulnerability exists in rsync. It stems from behavior enabled by the --inc-recursive option, a default-enabled option for many client options and can be enabled by the server even if not explicitly enabled by the client. When using the --inc-recursive option, a lack of proper symlink verification coupled with deduplication checks occurring on a per-file-list basis could allow a server to write files outside of the client's intended destination directory. A malicious server could write malicious files to arbitrary locations named after valid directories/paths on the client.
Passing of unsanitized strings from DHCP replies into the wicked dhcp client before wicked 0.6.79 could be used by attackers operating a malicious DHCP server to execute code on the local machine.
Impact
A malicious user with permission to edit the local-path-config ConfigMap in the local-path-storage namespace can manipulate the helperPod.yaml template used by rancher/local-path-provisioner.
The helperPod.yaml template is loaded by the provisioner and used to create HelperPods during PVC provisioning and cleanup operations. However, the template is not sufficiently validated before use. Security-sensitive fields such as securityContext.privileged, hostPath volumes, and Linux capabilities can be injected into the template.
Example malicious HelperPod template:
~~~yaml apiVersion: v1 kind: Pod metadata: name: helper-pod spec: containers: - name: helper-pod image: docker.io/kindest/local-path-helper:v20230510-486859a6 imagePullPolicy: IfNotPresent securityContext: privileged: true volumeMounts: - name: host-root mountPath: /host volumes: - name: host-root hostPath: path: / type: Directory ~~~
When a PVC operation triggers HelperPod creation, the provisioner creates the HelperPod using the attacker-controlled template. This can result in a privileged pod running on the target node with the host root filesystem mounted.
This may allow the attacker to access sensitive host files, read ServiceAccount tokens from other pods on the same node, access other tenants' local-path volume data, or modify files on the host node.
Expected Behavior:
- The HelperPod template should not allow privileged containers. - The HelperPod template should not allow arbitrary hostPath mounts. - Security-sensitive fields in helperPod.yaml should be validated or rejected before the provisioner creates HelperPods.
Patches
This vulnerability is addressed by validating the HelperPod template loaded from the local-path-config ConfigMap before it is used to create HelperPods.
The fix ensures that unsafe fields such as privileged security contexts, hostPath volumes, and other dangerous pod security settings are rejected. This prevents an attacker with ConfigMap edit permission from injecting a malicious HelperPod template that grants access to the host node.
Previously, a malicious user could modify helperPod.yaml to cause the provisioner to create a privileged HelperPod with the host root filesystem mounted, potentially leading to node-level compromise and ServiceAccount token theft.
With this fix, HelperPod templates containing unsafe security-sensitive fields are denied, and only safe HelperPod configurations are accepted.
Patched versions of local-path-provisioner include releases v0.0.34 and later.
No patches are provided for earlier releases, as they do not include the necessary HelperPod template validation logic.
Workarounds
Users should upgrade to a patched version of local-path-provisioner to fully mitigate this vulnerability.
As a temporary mitigation, users can restrict write access to the local-path-config ConfigMap in the local-path-storage namespace. Only trusted administrators should be allowed to update this ConfigMap.
Users may also mark the ConfigMap as immutable after deployment:
~~~bash kubectl -n local-path-storage patch configmap local-path-config \ --type merge -p '{"immutable": true}' ~~~
Additionally, enabling Kubernetes Pod Security Admission for the local-path-storage namespace can provide defense in depth. For example, enforcing the baseline policy can prevent privileged HelperPods from being created even if the template is modified:
~~~bash kubectl label namespace local-path-storage \ pod-security.kubernetes.io/enforce=baseline \ pod-security.kubernetes.io/warn=restricted ~~~
These mitigations reduce the risk of exploitation, but upgrading to a patched release is required to fully address the issue.
References
If you have any questions or comments about this advisory:
- Contact the SUSE Rancher Security team for security related inquiries. - Open an issue in the Rancher repository.
The Service Location Protocol (SLP, RFC 2608) allows an unauthenticated, remote attacker to register arbitrary services. This could allow the attacker to use spoofed UDP traffic to conduct a denial-of-service attack with a significant amplification factor.
A Race Condition Enabling Link Following vulnerability in the packaging of 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 to corrupt files or potentially escalate privileges. 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.
An use after free flaw was found in the audio component of the Chromium browser.
Upstream bug(s):
https://code.google.com/p/chromium/issues/detail?id=1059686
External References:
https://chromereleases.googleblog.com/2020/03/stable-channel-update-for-desktop18.html
An use after free flaw was found in the media component of the Chromium browser.
Upstream bug(s):
https://code.google.com/p/chromium/issues/detail?id=1031142
External References:
https://chromereleases.googleblog.com/2020/03/stable-channel-update-for-desktop18.html
An use after free flaw was found in the audio component of the Chromium browser.
Upstream bug(s):
https://code.google.com/p/chromium/issues/detail?id=1057627
External References:
https://chromereleases.googleblog.com/2020/03/stable-channel-update-for-desktop18.html
An use after free flaw was found in the audio component of the Chromium browser.
Upstream bug(s):
https://code.google.com/p/chromium/issues/detail?id=1057593
External References:
https://chromereleases.googleblog.com/2020/03/stable-channel-update-for-desktop18.html
An use after free flaw was found in the audio component of the Chromium browser.
Upstream bug(s):
https://code.google.com/p/chromium/issues/detail?id=1055788
External References:
https://chromereleases.googleblog.com/2020/03/stable-channel-update-for-desktop18.html
An inappropriate implementation flaw was found in the JavaScript component of the Chromium browser.
Upstream bug(s):
https://code.google.com/p/chromium/issues/detail?id=1029576
External References:
https://chromereleases.googleblog.com/2020/02/stable-channel-update-for-desktop.html
An insufficient data validation flaw was found in the streams component of the Chromium browser.
Upstream bug(s):
https://code.google.com/p/chromium/issues/detail?id=1031895
External References:
https://chromereleases.googleblog.com/2020/02/stable-channel-update-for-desktop.html
An use after free flaw was found in the WebGL component of the Chromium browser.
Upstream bug(s):
https://code.google.com/p/chromium/issues/detail?id=1051748
External References:
https://chromereleases.googleblog.com/2020/03/stable-channel-update-for-desktop18.html
An use after free flaw was found in the audio component of the Chromium browser.
Upstream bug(s):
https://code.google.com/p/chromium/issues/detail?id=1042254
External References:
https://chromereleases.googleblog.com/2020/02/stable-channel-update-for-desktop.html
An inappropriate implementation flaw was found in the Blink component of the Chromium browser.
Upstream bug(s):
https://code.google.com/p/chromium/issues/detail?id=1024256
External References:
https://chromereleases.googleblog.com/2020/02/stable-channel-update-for-desktop.html
An insufficient policy enforcement flaw was found in the downloads component of the Chromium browser.
Upstream bug(s):
https://code.google.com/p/chromium/issues/detail?id=1029375
External References:
https://chromereleases.googleblog.com/2020/02/stable-channel-update-for-desktop.html
An uninitialized use flaw was found in the PDFium component of the Chromium browser.
Upstream bug(s):
https://code.google.com/p/chromium/issues/detail?id=1032090
External References:
https://chromereleases.googleblog.com/2020/02/stable-channel-update-for-desktop.html
An insufficient policy enforcement flaw was found in the storage component of the Chromium browser.
Upstream bug(s):
https://code.google.com/p/chromium/issues/detail?id=1035399
External References:
https://chromereleases.googleblog.com/2020/02/stable-channel-update-for-desktop.html