KDE plasma-login-manager privileged helper can enable plasmalogin-to-root escalation

The new upstream added a privileged D-Bus helper called plasmaloginauthhelper, which suffers from multiple issues, e.g.aA compromised plasmalogin service account can chown() arbitrary files in the system.

The normalized record identifies KDE plasma-login-manager as affected. It also sets the product-level default_status to unaffected while recording a separate affected custom version entry of 0 with lessThan: ?; this does not provide a usable upper version boundary.

The SUSE technical review examined version 6.6.2 and described the plasmaloginauthhelper issues in that code. The advisory said a fix was planned for the next Plasma release, but it did not provide an exact fixed version. Later or parallel release branches should not be treated as unaffected without separate confirmation.

KDE plasma-login-manager adds plasmaloginauthhelper, a privileged D-Bus helper that runs with full root privileges and processes client-supplied data. The org.kde.kcontrol.kcmplasmalogin interface is exposed on the system bus, while its sync(), reset(), and save() actions are protected by Polkit auth_admin by default.

• In sync(), the helper performs chown() operations on paths below /var/lib/plasmalogin, including .config, fontconfig, and configuration files. If the plasmalogin service account is already compromised, symbolic links at these locations can redirect ownership changes and client-supplied writes to arbitrary files on the system.
• In reset(), QDir::removeRecursively() is used on .cache and .config/fontconfig. Its handling of a symbolic link in the final path component can allow deletion of arbitrary directory trees.
• In save(), a race condition exists while /var/lib/plasmalogin/wallpapers is created and opened. A symbolic link can redirect wallpaper writes to another location. openat2() protects the files placed inside the directory, but not the directory that is opened first.
• save() also lacks a limit on wallpaper storage, does not adequately validate the type and flags of passed file descriptors, and writes caller-controlled content to /etc/plasmalogin.conf without structure or size validation. SUSE describes the configuration validation issue primarily as a robustness problem rather than a direct security issue.

The root cause identified by the source is that the helper does not drop privileges before performing file-system operations in the service account's home directory.

This is a locally reachable issue. The normalized record characterizes the attack as low complexity, requiring low privileges, with passive user interaction. SUSE states that none of the reported issues is exploitable in a default installation and describes the principal abuse case as requiring a previously compromised plasmalogin service account.

The D-Bus interface is available to users on the system bus, but the reviewed actions require Polkit auth_admin by default. A changed Polkit policy could alter the exposure, but the available evidence does not confirm a specific weak deployment.

The record does not establish observed exploitation. Its public-exploit flag is false, and no specific public exploit is identified. This does not prove that exploitation has never occurred.

The primary technical outcome is a local privilege-boundary failure: the plasmalogin service account can potentially use a helper running as root to affect files and directories outside its intended scope. Directly documented consequences include arbitrary ownership changes and writes through symbolic links, arbitrary directory-tree deletion, redirected wallpaper writes, and disk-space exhaustion.

These effects can damage system integrity or availability and can break plasma-login-manager configuration. If a successful abuse path reaches root, host-wide confidentiality impact could also become possible because the attacker would gain system-level authority, although the source does not describe a specific data-read operation. The important precondition is compromise of the plasmalogin account or a weaker-than-default authorization policy; the source does not confirm exploitation in a default installation.

A compromised plasmalogin service account could use the helper to undermine a critical privilege boundary on KDE systems:

• System integrity: symbolic links can redirect chown() and write operations outside the service account's intended directory.
• Availability: recursive deletion can remove arbitrary directory trees, while unrestricted wallpaper writes can exhaust disk space.
• Login operations: configuration and wallpaper data used by plasma-login-manager could be altered or removed, causing malfunction or service disruption.
• Privilege scope: if the abuse reaches root, the potential impact extends across the host, although the source does not identify a real-world incident or breach.

This is primarily a defense-in-depth failure after compromise of the service account, not evidence of a direct remote attack.

1. Apply a vendor-confirmed fixed update for KDE plasma-login-manager when an exact fixed release is established. Current evidence does not establish the fixed version, so do not convert the planned release into an open-ended version range.
2. Until a verified fix is deployed, do not weaken the default Polkit protection for sync(), reset(), or save() below auth_admin. This reduces exposure but does not remove the underlying defect.
3. For maintainers, make the helper drop privileges to the plasmalogin account before performing file-system operations in /var/lib/plasmalogin. Each path component still requires careful validation to prevent symbolic links and special objects such as named FIFOs from creating denial-of-service paths.
4. Add structure and size validation for /etc/plasmalogin.conf, impose a maximum wallpaper storage limit, and verify that passed file descriptors refer to regular files without unexpected flags such as O_PATH.
5. After updating, recheck the package version, Polkit policy, and integrity of the affected data paths to confirm that the fix is deployed consistently across each release branch.

1. Inventory systems running KDE plasma-login-manager and determine whether plasmaloginauthhelper is installed. Compare the deployed package with the vendor's confirmed fixed release; the available evidence does not establish an exact fixed-version boundary.
2. Review the Polkit policy applied to sync(), reset(), and save(). Confirm that the actions still require auth_admin and have not been relaxed to a broader authorization setting.
3. Perform a precautionary integrity review of /var/lib/plasmalogin, especially .config, .cache, .config/fontconfig, and wallpapers. Look for unexpected symbolic links, ownership, or file changes.
4. Review /etc/plasmalogin.conf and the wallpaper directory for unexplained modifications or abnormal disk consumption. These are precautionary checks derived from the affected paths, not known indicators of compromise published by the source.
5. Review available D-Bus and file-system audit telemetry for unexpected calls to org.kde.kcontrol.kcmplasmalogin or related changes. No specific log event or IOC is established; absence of such evidence does not prove that the system is safe.