UYUNI is an open source system management solution, forked from Spacewalk and upstream community project from which SUSE Multi-Linux Manager is derived.
The audit started in January 2024 with the perimeter definition. Since it’s not feasible to audit everything, a list of packages was chosen and submitted to UYUNI product owner. The criteria for including a package in the perimeter were:
salt package (fundamental for UYUNI server and minions interaction)In March 2024 the code scanning activities effectively started.
Auditing a complex codebase like UYUNI is not just running a static analysis tool and waiting for it to complete. It is a complex and long-running journey that took one year and a half to complete.
The codebase is big with a lot of sub-packages. Each sub-package was treated as a standalone audit with its own Bugzilla bug, its own list of affected vulnerabilities and its own report. The final report was produced by combining the reports of all sub-packages.
The audited codebase is more than 4.5 millions lines of code, with at least 7 different programming languages.
| Language | Files | Lines of code |
|---|---|---|
| JavaScript | 2547 | 3805282 |
| Java | 4052 | 369100 |
| Go | 795 | 250684 |
| Python | 407 | 103965 |
| JSP | 641 | 36861 |
| Shell | 86 | 6744 |
| Perl | 65 | 6070 |
As you may wonder, using a single catch-all tool to analyze such a heterogeneous codebase is not possible.
Every package in the scanning perimeter was audited looking at the source both using tools and by manual inspection. The running server was continuously inspected dynamically looking for low-hanging fruit like cross-site-scripting (XSS), SQL injection and similar, and for business logic flaws.
Each security issue was then triaged and if necessary a CVE identifier was assigned and the vulnerability put under EMBARGO. Using the openSUSE coordinated disclosure policy as a framework, we coordinate with upstream and disclose the issue when solved.
We use Bugzilla as tracking authority for audits and vulnerabilities found during the activity. A master bug (boo#1218619) was created with the purpose of acting as a main container for all sub-packages audit bugs.
Each audit bug contains all affecting vulnerabilities and, of course, a vulnerability bug can be set as blocker to more sub-packages.
For the activity, a set of KVM-powered machines were created:
The server is the main UYUNI component orchestrating minions attestation and enabling system administrators to launch commands and interact with minions using the web interface.
A minion, in the UYUNI slang, is a Linux-powered machine (ideally it is a client in a local network), connected to the server.
A UYUNI proxy is a particular kind of server, used to fetch packages from software distribution channels and centrally store software packages for an efficient distribution to minions. Distribution channels are software repositories and a system administrator subscribes his own UYUNI instance to different repositories.
Each server was running openSUSE MicroOS as underlying operating system and minions were running either openSUSE Tumbleweed or Ubuntu Linux distributions.
For the testing activities we used two different machines. A virtual machine running openSUSE Tumbleweed, used for source code inspection and a virtual machine running Kali Linux installed to help in penetration testing activities.
Burp Suite community was the main tool used trying to spot security issues in the running application.
To help, during the UYUNI application browsing, a custom tool was developed. While browsing the web UI trying to find business logic flaws, I felt the need for something running in the background spotting low-hanging fruit in web pages form, cookies and more. The tool eventually became an OSS project named nightcrawler-mitm. It’s a mitmproxy extension implementing both an active and a passive scanner running several security controls in the background.
Also for auditing the source code, opensource tools were used. Some of the tools used are famous OSS projects, like:
To help me during the activities, I also used some SAST tools previously written by myself, like:
As discussed before, every finding was tracked on a separate bugzilla bug. Each bug was linked, marking as a blocking bug, to any sub-package audit bug affected by the associated vulnerability.
Of course, every vulnerability was confirmed by a successful exploitation, before being added to our Bugzilla tracking system. Vulnerabilities were assigned to UYUNI developers and tracked until a fix was released. A CVE was also assigned if required by the issue severity.
The standard CVSS version 4 was used as a scoring system and to assign a severity. The rationale is that if a CVSS is lower than 5, then the severity is low, it is medium if CVSS is between 5 and 7 and high otherwise. The same approach was used to assign a triage score to each sub-package. The triage score will be used in the future to decide if the sub-package must be in future audit perimeter or not.
At the end of the audit, the list of issues and the triage score created a technical report sent to UYUNI developers.
During the audit, seven CVEs were found and fixed, and numerous minor issues were addressed, improving the product’s reliability and overall security posture.
A reflected cross-site scripting has been found in the HTTP proxy pane of the setup wizard UI element. Tracked in boo#1231852
A reflected cross-site scripting has been found in the Organization Credentials pane of the setup wizard UI element. Tracked in boo#1231922
Some URLs, served by the SystemsController.java class are vulnerable to a reflected XSS vulnerability. Some example of vulnerable URLs are listed in the Github advisory as well. The
advisory
was filed by an external independent researcher following
our coordinated disclosure policy.
Tracked in boo#1239826
Credentials to be used in UYUNI HTTP proxy are disclosed in the error log in case of wrong port number or misspelled hostname. Tracked in boo#1245005
During an internal assessment, a customer found an issue with the remote-commands websocket endpoint (/rhn/websocket/minion/remote-commands).
Using websockets, anyone with the ability to connect to port 443 of SUSE Manager is able to run any command as root on any client with no authentication. The customer using our coordinated disclosure policy as a reference, reported the issue which was then fixed and publicly disclosed. Tracked in
boo#1246119
During an internal assessment, a customer found that some reflected cross-site scriptings were possible due to improper input validation. The issue was tracked in the private SUSE bugzilla instance, since some customer sensitive information was included. However the issue is described in the public CVE-2025-53883 page.
A Path Traversal vulnerability in the tftpsync/add and tftpsync/delete scripts allows a remote attacker on an adjacent network to write or delete files on the filesystem with the privileges of the unprivileged wwwrun user. Although the endpoint is unauthenticated, access is restricted to a list of allowed IP addresses. The unprivileged user has write access to a directory that controls the provisioning of other systems, leading to a full compromise of those subsequent systems. Tracked in
boo#1246277
Additional vulnerabilities were identified that, while valid, did not meet the criteria for CVE assignment:
Last but not least, during the audit also some codebase improvements were suggested to raise the security posture even further:
The UYUNI audit was an intense and rewarding run. The good results in term of number of found vulnerabilities and the fast reaction to release the fixes, confirmed UYUNI as a solid and reliable product for the community.
As all software, of course it can be improved in terms of code quality by applying safe coding patterns, using secure and reliable third-party libraries and consolidating the usage of one or two programming languages. This is an important step, because it creates a common ground for engineers and a solid codebase for the community to entice contributions and pull requests.
A vibrant codebase, using a balanced mix between standard and cutting edge technologies can increase adoption of the product and it can attract developers and contributors.
It also helps in adopting safe coding best practices that are widely updated and developed for newer technologies rather than ancient and not actively used programming languages.
The low number of vulnerabilities found, and the reaction time in fixing the serious ones, indicate that the project is well-curated and actively maintained. The security posture is good and it can be safely deployed in production.
Like every journey, the final destination is not the reward itself. The UYUNI project is actively under development with a monthly (more or less) release cycle.
The next audit will start in the first quarter of 2026 and it will be another one year and a half rollercoaster ride, with rabbit holes, false positives, suspected CVEs turning out to be not exploitable and real root dance issues.
The fun part is to audit code written in multiple languages, with different stacks and libraries.
It’s not rewarding only from a security perspective, it’s a real learning experience.
systemd v258 Code Reviewplasma-setup KDE Package
plocate Binaryvirtualbmc Project
snapd Package ManagerThe winter season has already begun for most of the people in our team and with the Christmas holidays behind us, which granted us some well-earned rest, we want to take a look back at what happened in our team during the autumn months. During this time we already published a few dedicated review reports:
OpenSMTPD mail
transfer agent.scx scheduler project allowing
for a major local Denial-of-Service.lightdm to root in
lightdm-kde-greeter leading to major improvements of its D-Bus code.smb4k, resulting in upstream fixing a series of
long-standing issues in the affected component.In this post, as usual in the spotlight series, we will look into some topics
that did not justify dedicated reports. First we will discuss our continued
efforts to review privileged components found in the
systemd v258 release, which involved diving deep into some low-level aspects
of the Linux kernel API. Section 3 looks at D-Bus
issues we found in plasma-setup, a new component for the KDE desktop.
Section 4 covers recent discussions about granting special
setgid permissions to the plocate package. Section 5
gives insight into security issues found in the virtualbmc OpenStack
project, which turned out to be for testing purposes only. Section
6 discusses revived efforts to bring the Snap package manager
to openSUSE.
systemd v258 Code ReviewWe already discussed our systemd v258 review efforts in the previous
spotlight edition. At the time we found a
local root exploit in the systemd-machined API, which could be fixed before
the final release of v258. For the addition of this new major version of
systemd to openSUSE Tumbleweed, we still needed to look more closely into a
number of other D-Bus and Varlink services that have been added.
During autumn we completed the review of changes in
systemd-mountfsd and
systemd-nsresourced. Some of the changes
introduced with these services allow unprivileged users to perform a number of
container-related operations without requiring special privileges.
The io.systemd.MountFileSystem.MountDirectory API
call in mountfsd, for example, allows to obtain
a mount file descriptor for a directory owned by the calling user, on which a
user and group ID mapping is applied corresponding to a user namespace file
descriptor also owned by the caller. Some newer, little-known Linux system
calls like open_tree() and
mount_setattr() are used to achieve this. This niche
topic and the low-level nature of the involved APIs result in quite complex
code which needed careful reviewing. We are happy to report that we could find
no issues in this area, however.
The nsresourced service, among other features, allows unprivileged users to
obtain a dynamic range of user and group IDs for use with user namespaces. The
tools newuidmap and newgidmap already
allowed this for a longer time based on static configuration files. The
nsresourced service applies dynamic limits and ID ranges to processes in
the system, however, which makes things quite more complicated. This even
includes an EBPF program, which keeps track
of the uses of the resulting user namespace file descriptors. Despite this
complexity we could not find any issues in this component either.
What kept us busy for a longer time was logic
invoked by mountfsd to obtain the
user and group ID mapping tied to the user namespace file descriptor passed by
the unprivileged client. To retrieve this information, the utility function
ns_enter_and_pin() forks a short-lived
child process which joins the user namespace provided by the client. The
parent process then reads the child’s uid_map and gid_map nodes from
/proc/<child-pid>.
The mountfsd daemon runs with root privileges (although some sandboxing is
applied to it as well), which will be inherited by the short-lived child
process. Once the child process joins the user namespace provided by the
unprivileged client, the security domain of this process changes, however,
because the client owning the namespace is supposed to have full control over
processes associated with it.
One consequence of this is that the owner of the user namespace can send
arbitrary signals to the short-lived systemd process, e.g. to kill it. This
would only result in a kind of Denial-of-Service against the client itself and
should not cause any security issues.
We expected another important ramification of this to be in the area of the
ptrace() system call. The following is stated in the “ptrace
access mode checking” section of the ptrace(2) man page:
(3) Deny access if neither of the following is true:
• The real, effective, and saved-set user IDs of the target
match the caller's user ID, and the real, effective, and
saved-set group IDs of the target match the caller's group
ID.
• The caller has the CAP_SYS_PTRACE capability in the user
namespace of the target.
According to the second item, the unprivileged client, which owns all
capabilities in its user namespace, should be able to trace the short-lived
systemd process which joins the client-controlled user namespace. This
ability would have allowed for an interesting privilege escalation, because
tracing capabilities also include the ability to modify the target process,
e.g. to change its code and data. While trying to reproduce this, the kernel
always denied ptrace() access to this short-lived process, however, and we
were not sure why. Unclarity in such aspects is not a good thing when it
concerns security, thus we set out to get to the bottom of this.
After diving deep into the Linux kernel’s ptrace() code, we found the
commit which is responsible for the rejection of
tracing access in this scenario. The background of this commit actually is
to prevent owners of unprivileged user namespaces from accessing the
executable of processes created in the initial namespace. ptrace() access to
the target PID is now only allowed if the target process performed an
execve() while being a member of the newly joined user namespace. In summary
this means the following:
fork() and setns() to join a user namespace,
then ptrace() access to this process is denied to the owner of the user
namespace.fork(), setns() and execve(), then ptrace()
access to this process is granted to the owner of the user namespace.This detail is not documented in the ptrace() man page and it
took us a while to fully understand what was going on. With this well
understood we could finally move on, knowing that the logic in mountfsd is
robust.
plasma-setup KDE PackageThis new KDE component was first named KISS (KDE initial system setup), but
meanwhile has been renamed to plasma-setup.
Its purpose is to perform initial system configuration based on a graphical
wizard, when a Linux system has been freshly installed.
Our openSUSE KDE packagers asked for a review of this new component, expecting it to be part of a major KDE release in autumn. It turned out that this had not been planned by upstream after all (or plans changed). Still the review we performed turned out to be useful, since we identified various security problems in the existing code which could be fixed by upstream before the new component had seen production use.
The following report is based on the plasma-setup source code as of upstream
commit 08ed810e0e7. While the graphical
components of plasma-setup run with low privileges, there exists a D-Bus
helper service running as root, kde-initial-system-setup-auth-helper,
which allows to perform a number of operations with elevated privileges. These
operations are guarded by Polkit authorization rules. The dedicated user
account kde-initial-system-setup is allowed to invoke any of these actions
without authentication. Beyond this, any locally logged-in users are also
allowed to invoke the operations without authentication. The latter is quite
problematic, as will be outlined below.
The implementation of the D-Bus callbacks for these actions is found in
src/auth/authhelper.cpp. The following
sub-sections discuss issues in a couple of these actions.
This action receives a “username” parameter
from the unprivileged D-Bus client. The username is not verified by the
privileged helper, it only needs to be convertible to QString. The helper
then creates all the directory components of
/home/<username>/.config/autostart. After this, the file
/home/<username>/.config/autostart/remove-autologin.desktop is created and
fixed data is written into it.
This action allows local users to create arbitrary world-readable directories
owned by root. This can be achieved by passing a string like
../../my/desired/path as “username”. Furthermore, by placing a symlink at
the expected location of remove-autologin.desktop, arbitrary files in the
system can be overwritten, leading to a local Denial-of-Service.
The implementation of the action also causes the created directories and files
to be owned by root:root, and not by the user that actually owns the home
directory, which is unclean.
Apart from restricting access to the helper to the kde-initial-system-setup
user, the implementation of this action should verify whether the
passed-in username actually exists. Furthermore, the home directory of this
account should be obtained via the getpwent() API, instead
of assuming that /home/<username> will always be the correct home directory.
When the execution of this helper is actually limited to the initial setup
context, it could be technically acceptable to operate as root in the newly
created user’s home directory. For reasons of prudence and giving a good
example, we still recommend to drop privileges to the target user account
before actually writing the .desktop file in the user’s home directory.
The method call associated with this action also receives a “username” parameter which is not verified. The following command line is invoked based on the “username” parameter:
chown -R <username>:<username> /home/<username>
This is on the verge of a local root exploit, save for the fact that chown
expects a valid user and group account to give the ownership to, which at the
same time needs to result in the proper path to operate on. A username
containing path elements will fail, because the necessary characters like /
are by default denied in usernames.
This action still allows to potentially change ownership of all files of
arbitrary other users’ home directories. Fortunately the recursive chown
algorithm is not subject to symlink attacks these days. If somebody would be
able to place a symlink in place of their home directory in
/home/<username>, then the symlink would still be followed, however.
The username could also be interpreted as an arbitrary command line argument
to chown, thwarted only by the fact that the <username>:<username>
argument is constructed here instead of just passing <username>, which will
prevent proper command line arguments from being passed.
As for the previous action, the implementation should verify if the username
is valid and determine the proper home directory and group via getpwent().
The assumption that username and group are equivalent is also problematic
here.
Why this operation would be needed at all for a newly created home directory
is questionable. When new user accounts are created, file ownership should
already be correct. If this action is supposed to fix the ownership of files
created by other plasma-setup actions in the home directory as root (as is
seen in the createnewuserautostarthook action),
then this is only a hack which should be removed in favor of not creating
files as root in unprivileged users’ home directories in the first place.
Again this method receives a “username”
parameter which is not verified. The
implementation writes the following content to the file
/etc/sddm.conf.d/99-kde-initial-system-setup.conf:
[Autologin]
User=<username>
Session=plasma
Relogin=true
This SDDM configuration snippet is supposed to automatically login the given user account. For some reason that we did not investigate more deeply, the configuration was not effective during our tests on openSUSE Tumbleweed. We could verify that the configuration file created this way was parsed and evaluated in SDDM, however, so something else must have been amiss.
The automatic login is supposed to work, though, and if it does, then any
local user account can call this action with root as username, which should
cause an automatic login of the root user the next time SDDM runs.
By passing crafted strings for “username”, the content of the drop-in configuration file can even be fully controlled by local users. The following “username” would create a General section with a crafted “RebootCommand”, for example:
user\n[General]\nRebootCommand=/home/myuser/evil
Provided the configuration snippet is actually in effect in SDDM, this action allows for a local root exploit.
As for the other actions, the implementation should verify whether the passed
“username” is valid and does not equal root.
We privately approached KDE security on 2025-09-22 with a detailed report
about these findings. As a result we established contact with the
plasma-setup developer and discussed fixes for the issues. It was decided to
perform the bugfix in the open, since the component was not yet part of a
stable release of KDE. We reviewed an upstream merge
request during the course of two weeks and upstream
managed to arrive at a much improved version of the KAuth helper component.
As of commit e6eb1cd9a8d the privileged
helper carefully scrutinizes the input parameters received via D-Bus, and it
also drops privileges to the calling user before operating in the unprivileged
user’s home directory. Also the KAuth actions provided by the helper are now
restricted to the plasma-setup service user and no longer accessible to
all locally logged-in users. The latter would still be problematic, since it
would allow to setup automatic login for arbitrary other users in the system,
for example.
plocate BinaryAn openSUSE community member approached us about granting special setgid
privileges to the plocate binary. plocate is a modern and
fast replacement for the classic locate program. Upstream supports operation
of the plocate program with the setgid bit assigned to the plocate
group. This means that the program is granted plocate group privileges
during execution.
When updatedb, locate’s utility for indexing files, would be invoked with
full root privileges, then the database in /var/lib/plocate would contain
information about all files in the file system. This way locate would grant
all users in the system read access to this information, resulting in an
information leak, because users can see paths that they would not normally be
allowed to list, like all the files stored in the /root home directory. For
this reason the plocate-updatedb system service on openSUSE Tumbleweed runs
as nobody:nobody, resulting in a system-wide plocate database which only
contains information about publicly accessible paths in the system. For being
able to locate their own private files, users need to create their own
user-specific databases instead.
The purpose of the setgid privilege is to address this locate database
access issue. plocate supports a mode in which updatedb is invoked with
full root privileges, but the ownership of the central database is changed to
root:plocate and file mode 0640. When plocate is installed as
setgid-plocate then it is still allowed to access the central database. The
program drops the special group credentials quickly again, right after opening
the database. The program then ensures that the calling user will only be able
to retrieve information about files that it is allowed to access based on its
real credentials.
There is a minor security issue found in this approach. Since the plocate
database does not contain metadata about the files it indexed, the plocate
program needs to check the ownership of files in the file system at the time
the search query runs. This is a sort of a TOCTOU (time-of-check time-of-use)
race condition. There can be situations when the verification in plocate
yields wrong results:
root# mkdir --mode=1777 /shared
root# mkdir --mode=0700 /shared/secret-dir
root# touch /shared/secret-dir/secret-file
root# updatedb
# root will be able to locate any files in secret-dir
root# locate /shared/se
/shared/secret-dir
/shared/secret-dir/secret-file
# non-root cannot locate the secret-file
user$ locate /shared/se
/shared/secret-dir
# now consider root deletes the secret-dir again
root# rm -rf /shared/secret-dir
# now the unprivileged user takes ownership of this path
user$ mkdir --mode=0755 /shared/secret-dir
# this only works before `updatedb` is called again, because then it will
# notice that secret-file no longer exists and delete it from the database.
#
# when the unprivileged user calls locate this time, the secret-file will show
# up, since the "secret-dir" is now controlled by the unprivileged caller.
user$ locate /shared/se
/shared/secret-dir
/shared/secret-dir/secret-file
This problem likely cannot be easily fixed in the plocate code, since it
would require changing the database format radically, increasing database size
as a result, only to fix an unlikely problem.
The information leak is minor and should rarely be exploitable. For this
reason we left it up to the openSUSE plocate package maintainer whether the
setgid-plocate approach should be used, or not.
virtualbmc ProjectBy way of our efforts to monitor newly introduced systemd services in
openSUSE Tumbleweed, the python-virtualbmc
package caught our attention. The program allows to emulate a board management
controller (BMC) interface for use with libvirt.
Part of the package is a daemon running with full root privileges, listening
for ZeroMQ API requests on localhost. A number of unauthenticated API calls
in this context raised our suspicions, which is why we scheduled a full
review of this package. A closer look showed that the
unauthenticated API calls were indeed problematic, even allowing for a full
local root exploit.
We filed a detailed private bug report on
LaunchPad for the OpenStack project, but had
difficulties getting a response. After some weeks we reached out to an
individual member of the OpenStack security team and learned from the reply
that the virtualbmc project was not intended for production use at all, but is
rather a utility intended for use in testing environments. This is also
documented in the repository’s README, which was
overlooked by us. As a result we filed a delete request for the
python-virtualbmc package in openSUSE Tumbleweed, and the package has
already been removed.
For completeness, a detailed report of the security issues in the virtualbmc daemon follows below.
vbmcdWhen the virtualbmc systemd service is started, then /usr/bin/vbmcd runs
with full root privileges. It offers a ZeroMQ-based network API, listening on
localhost port 50891 by default. Any local user in the system can talk to the
daemon this way.
A simple request which can be sent to the daemon (in JSON format) is the following stop command, for example:
{
"command": "stop",
"port": 1234,
"domain_names": ["../../home/myaccount/mydomain"],
}
The domain_name passed here will be used by the daemon to lookup a
supposedly trusted per-domain configuration file, which is by default located
in /root/.vbmc/<domain>/config. Since the daemon does not scrutinize the
input domain_name, a local attacker can include directory components in the
name, to trick the daemon into accessing an attacker-controlled configuration
file.
In the context of the stop command used here, the daemon will try to update
the domain’s configuration file in case a change of domain state is detected.
The path for writing out the updated configuration file will be constructed
using the domain_name found in the input configuration file. Thus the local
attacker can place data like this into /home/myaccount/mydomain/config:
[VirtualBMC]
domain_name = ../../etc/sudoers.d
port = 1234
active = true
address = some
evil stuff
myaccount ALL=(ALL:ALL) NOPASSWD: ALL
The daemon will now believe that the domain’s state changed, because the input
configuration file contains active = true, while the daemon was asked to
stop the domain. This will trigger logic to write out an updated configuration
file with the new state of the domain configuration. The logic for this is
found in the _vbmc_enabled() member
function.
Since the domain_name found in the crafted configuration file is set to
../../etc/sudoers.d, the daemon will write the new configuration file into
/root/.vbmcd/../../etc/sudoers.d/config. To get an advantage from this, the
attacker must get the daemon to write out at least one valid sudoers
configuration line into the new configuration file.
The attacker has only a limited degree of freedom at this stage, because
the daemon will write out the new configuration file via the Python
configparser module and will only consider the [VirtualBMC] section as
well as any of the configuration keys listed in the VBMC_OPTIONS
list defined in the daemon’s code.
To help with the exploit, the
configparser
multiline syntax comes to the rescue: any lines following an assignment which
are indented will be accepted as part of the configuration value. When writing
the settings out to a new configuration file, these multiline settings will be
preserved. This is put to use in the example above, which contains a final
line myaccount ALL=.... This line will now appear along with the rest of the
configuration data in /etc/sudoers.d/config.
As a result, when the attacker now invokes sudo su -, a couple of sudoers
parsing errors will appear, but in the end, access is granted and a root shell
will be obtained by the attacker.
This approach of using a sudoers drop-in configuration file is just one of the
more obvious approaches that came to mind. There’s a lot of different ways
to exploit this, however, for example by overwriting shell scripts or script
snippets in /etc or /usr/bin and then waiting for a privileged process to
run them. This would be even easier, because shell scripts have less
strict syntax requirements compared to the sudoers configuration file. The
effect would not be immediate, however, like in the sudoers approach.
We offer a Python script for download, which
is a Proof-of-Concept (PoC) to reproduce the local root exploit in the context
of an arbitrary unprivileged user on the system, when vbmcd is running with
its default configuration. sudo needs to be installed, naturally, for the
exploit to work.
In general, the API offered by vbmcd on localhost is missing input
sanitization and authorization. Authorization seems only to be performed
indirectly via libvirt. In this context clients can also pass crafted
libvirt_uri parameters, for example, which seem to make it possible to let
the daemon connect to arbitrary URLs via SSH. There also is no isolation
between different users’ domain configurations, e.g. the “stop” command used
above can be issued for any domain configured by another user in the system.
To make this API safe, we believe there needs to be an ownership model for each domain’s configuration, a verification of the client’s credentials in some form (a UNIX domain socket would allow this more easily) and sanitization of all input parameters to avoid any unexpected side effects.
Since the daemon listens on an unprivileged port on localhost, other
unprivileged users can try to bind to this port first and provide a fake
vbmcd service. Since the API requests can also contain secret credentials,
this would pose a major local information leak. For safe operation, the API
would need to bind to a privileged port on localhost instead.
snapd Package ManagerIn 2019 we received a request to add the snapd package
manager to openSUSE, which involved a review of the
setuid-root program snap-confine. At the time we were
generally satisfied with the code quality and design of the program, but still
found a few low to medium severity security issues
and gave recommendations on how to improve the code in some spots. The
packagers have meanwhile been busy with other topics and we never saw
an updated openSUSE package containing the necessary changes, which is why we
closed the related bugs after a period of inactivity.
In August we received a follow-up request for addition of an
updated snapd package. We revisited the privileged components and again
provided feedback to upstream. This time
all remaining issues could be resolved and the new package has been allowed to
become part of openSUSE Tumbleweed. We are happy to see these old efforts not
going completely to waste, and welcome the possibility to use Snap packages on
openSUSE Tumbleweed in the future.
Again we hope we’ve been able to give you some additional insight into our efforts to maintain the security of SUSE distributions and open source software. We are looking forward to the next edition of the spotlight series, which will be published in about three months from now.
]]>InputPlumber is a utility for combining Linux input devices into virtual input devices. It is mostly used in the context of Linux gaming and is part of SteamOS.
An openSUSE community member packaged InputPlumber which required a review by the SUSE security team, as it contains a D-Bus system service. The first version of InputPlumber we reviewed was completely lacking client authentication, causing us to reject it. A follow-up version contained Polkit authentication, which turned out to be lacking in multiple regards. At this point we approached upstream with a detailed report and established coordinated disclosure. Starting with version v0.69.0 of InputPlumber most (but not all) of the issues in this report have been addressed. SteamOS also published new images for version 3.7.20 containing the fixes.
This report is based on InputPlumber release v0.67.0. The next section provides an overview of InputPlumber’s D-Bus service. Section 3 looks into the security issues in detail. Section 4 discusses the fixes we suggested to upstream. Section 5 looks into the upstream bugfixes to address the issues and aspects that remain unfixed. Section 6 covers the CVE assignments we did for the issues we found. Section 7 provides a summary of the coordinated disclosure process we followed for this report.
InputPlumber is implemented in Rust and the size of the code base is surprisingly high for this type of project, adding up to about 50,000 lines of code overall (not counting vendor code) and about 3,000 lines dedicated to the D-Bus API specifically.
The InputPlumber D-Bus service runs with full root privileges, offering the “org.shadowblip.InputManager” interface on the D-Bus system bus. Additionally various interfaces representing Linux input devices are provided by the daemon, like a keyboard interface. In summary the service provides around 90 different D-Bus properties and about 10 different interfaces on various objects exported by it. The Polkit policy lists over 100 different actions, controlling every aspect of the D-Bus API including read/write access to individual properties.
Initially we looked into InputPlumber version
v0.62.2. In this version there is no Polkit
authorization at all for the D-Bus interfaces. There are also no
restrictions in the configuration of the D-Bus service, allowing all users in
the system to connect to it, even low privilege user accounts like nobody.
We thought about reaching out to upstream already at this point, when we noticed that in InputPlumber version v0.63.0 (which was meanwhile published on GitHub) Polkit authentication had been added via commit 0a80f3d85. Thus we asked our community maintainer to update the package to at least that version for us to have another look.
Due to other priorities we only got around to taking a fresh look at the package at a later time, when the package had already been updated to version v0.67.0, on which this report is based.
Looking into this version we first discovered that the Polkit authentication was still not effective in the package build provided to us. The reason for this was that Polkit support was only a compile-time feature on Rust Cargo configuration level - which was disabled by default. We believe that in this version there is also no canonical way to enable the feature when using the Makefile found in the repository. For this reason we created our own build of InputPlumber and applied a patch to hard-enable the Polkit feature for testing.
In this custom package build of InputPlumber the Polkit authentication
triggered as expected. While looking into the implementation of the Polkit
authentication wrapper, however, we noticed that the Polkit
authentication logic uses the “unix-process” Polkit subject in an unsafe way.
It retrieves the caller’s PID from the D-Bus connection and passes this
information on to the Polkit daemon. This suffers from a race condition,
because the client can attempt to have its PID replaced by a privileged
process by the time polkitd gets around to actually look at the credentials
of the process.
This is a well-known issue when using the “unix-process” Polkit subject which was assigned CVE-2013-4288 in the past. For this reason the subject has been marked as deprecated in Polkit. The “unix-process” subject is seeing new use these days, however, when combined with the use of Linux PID file descriptors, which are not affected by the race condition.
In summary none of the versions of InputPlumber we looked into provided sufficient authentication, even if integrators would have managed to actually enable the Polkit layer in versions v0.63.0 and later. Thus all InputPlumber D-Bus methods can be considered accessible by all users in the system without authentication.
Considering the unprivileged access to the D-Bus methods provided by InputPlumber, the following two methods quickly caught our attention as being problematic:
CreateCompositeDevice(in s config_path)This method parses the provided input path as YAML to create a CompositeDevice configuration and suffers from the following issues:
/dev/zero
as input file, leading to memory exhaustion in InputPlumber)./root/.bash_history:
user $ gdbus call -y -d org.shadowblip.InputPlumber -o /org/shadowblip/InputPlumber/Manager \
-m org.shadowblip.InputManager.CreateCompositeDevice /root/.bash_history
Error: GDBus.Error:org.freedesktop.DBus.Error.Failed: Unable to deserialize: invalid type: string "cd /etc/polkit-1/rules.d/", expected struct CompositeDeviceConfig at line 2 column 1
The string cd /etc/polkit-1/rules.d is an entry from root’s history file
in this case.
CreateTargetDevice(in s kind)This method allows to create a virtual keyboard input device like this:
user $ gdbus call -y -d org.shadowblip.InputPlumber -o /org/shadowblip/InputPlumber/Manager \
-m org.shadowblip.InputManager.CreateTargetDevice keyboard
Once the virtual keyboard has been created, key presses can be injected into the active user session (login terminal or graphical desktop) like this:
user $ gdbus call -y -d org.shadowblip.InputPlumber -o /org/shadowblip/InputPlumber/devices/target/keyboard0 \
-m org.shadowblip.Input.Keyboard.SendKey KEY_R true
All supported key symbols are found in keyboard.rs.
Using this ability, any user in the system can inject input to an active
desktop session or the active login terminal screen, possibly leading to
arbitrary code execution in the context of the currently logged in user, if
any.
We suggested the following action items to upstream to improve the security of the InputPlumber D-Bus API:
inputplumber systemd service. By using settings
like ProtectSystem=full the service can be tightened to avoid any unexpected
side effects when things go wrong at the first line of defense.Upstream mostly followed our suggestions and fixed the issues as follows:
All of these fixes are contained in InputPlumber version v0.69.0 and later.
Upstream initially wanted to avoid breaking the D-Bus API by switching to file
descriptors instead of path names, as we suggested. We strongly recommended to
do this, however, to avoid various issues that can occur when clients pass
malicious file paths. An upstream developer then created a pull
request which introduces file descriptors in the API.
We provided feedback that this is going in the right direction, but suggested to
also perform checks on the file descriptors passed by clients to make sure they
refer to regular files and have no unusual open flags like O_PATH set.
At the time of publication of this report we noticed that the improvements of
the D-Bus API to use file descriptors have not been merged yet and are not
available in a release. Thus some aspects of the issues described in this
report remain unaddressed, although they are now at least protected by proper
Polkit authentication. Sensitive methods like CreateCompositeDevice also
require admin privileges to be called, thus
these are mostly defense-in-depth issues, or only relevant when integrators
or admins relax Polkit authentication requirements.
In agreement with upstream we performed the following CVE assignments corresponding to this report:
CVE-2025-66005: lack of authorization of the InputManager D-Bus interface in InputPlumber versions before v0.63.0 can lead to local Denial-of-Service, information leak or even privilege escalation in the context of the currently active user session.
CVE-2025-14338: Polkit authentication disabled by default and a race condition in the Polkit authorization check in versions before v0.69.0 can lead to the same issues as in CVE-2025-66005.
We informed upstream about the security issues on 2025-11-25 and offered coordinated disclosure. Upstream quickly confirmed the issues and agreed to follow coordinated disclosure. The developers discussed bugfixes with us, which they provided in public GitHub pull requests. This way the information about the issues was not fully private anymore, but we agreed to keep the full report private for a longer time, until new SteamOS images would be published, containing a fixed InputPlumber.
We found out only at the time of publication that not all aspects of the issues have been addressed in the bugfix release.
We want to thank the InputPlumber developers for their cooperation regarding this report.
| 2025-11-21 | We contacted one of the developers of InputPlumber, asking for the proper security contact for the project. |
| 2025-11-21 | We got a swift reply and learned that we reached the correct person for security reports already. |
| 2025-11-25 | We forwarded a detailed report outlining the issues in InputPlumber to upstream, offering coordinated disclosure. |
| 2025-11-25 | Upstream confirmed the issues and opted for coordinated disclosure. |
| 2025-12-08 | Upstream pointed us to a couple of public pull requests which should address the issues and asked us to review them. |
| 2025-12-10 | We provided feedback on the pull requests. The D-Bus API still used client-controlled paths at this point, and we suggested to turn them into file descriptors. We also pointed out that the issues were no longer fully private in light of the public pull requests, but suggested to keep the full report private for longer until an agreed upon date. |
| 2025-12-10 | We assigned CVEs for the issues and communicated them to upstream. |
| 2025-12-12 | Upstream informed us that they wanted to keep the original D-Bus API stable, but agreed to add an additional fix to use file descriptors anyway. |
| 2025-12-16 | We asked upstream whether they were able to agree on a general publication date for the report by now. |
| 2025-12-22 | Upstream pointed us to another public GitHub pull request introducing file descriptors in the D-Bus API. |
| 2025-12-22 | Upstream informed us that the publication date still needed further internal discussions and that they would get back to us. |
| 2025-12-23 | We provided feedback to upstream about the additional pull request. We generally agreed with the change but suggested to also check file descriptor type and flags on the service side, to avoid unexpected file descriptors being passed by clients. |
| 2025-12-27 | Upstream informed us that Valve was planning to publish new SteamOS images containing the InputPlumber fixes on January 9, which was agreed upon for general publication date of the full report. |
| 2025-01-09 | Upstream informed us about publication of the new SteamOS images, thanking us for our support. |
| 2025-01-09 | Publication of this report. |
Foomuuri is an nftables-based firewall manager for Linux. The project includes a D-Bus daemon which offers an API similar to firewalld. In early December an openSUSE community member asked us to review Foomuuri for addition to openSUSE Tumbleweed.
During the review we quickly noticed a lack of client authorization and input validation in the implementation of Foomuuri’s D-Bus service. We reported the issues to upstream and performed coordinated disclosure. Upstream published version 0.31 of Foomuuri on 2026-01-07 which contains bugfixes for the security issues.
The next section provides an overview of the Foomuuri D-Bus service. Section 3) discusses the security issues in detail. Section 4) provides an overview of the upstream bugfixes to address the issues. Section 5) looks into the CVEs which were assigned. Section 6) gives insight into the coordinated disclosure process which was established for these findings.
This report is based on Foomuuri release v0.29.
Foomuuri runs with full root privileges and registers a D-Bus interface under the name”fi.foobar.Foomuuri1”. Optionally a firewalld drop-in replacement interface is also registered under “org.fedoraproject.FirewallD1”. Both interfaces hook into the same logic, however, and there is no need to look at them separately.
There are only a few methods provided by the D-Bus interface: getting the list of available zones and managing the assignment of network interfaces to zones.
There is no authentication layer like Polkit present in the Foomuuri D-Bus service, and there are also no restrictions on D-Bus configuration level as to who is allowed to connect to the D-Bus interfaces provided.
As a result any local user, including low privilege service user accounts or
even nobody, can invoke the D-Bus interface and change the firewall
configuration. The only state which can be modified this way is the assignment
of interfaces to zones, but this is enough to weaken the firewall
configuration or to perform a limited Denial-of-Service.
Apart from the lack of access restrictions pointed out above, the input
parameters to the D-Bus methods are not carefully scrutinized. While the zone
input parameter is at least checked against currently configured
zones, no further checks are performed on the
interface parameter. This means that, e.g. via the “addInterface” D-Bus
method, arbitrary strings can be passed as interface name. There is also
intentionally no check if the specified name corresponds to an existing
network device in the system (to allow seamless coverage of network devices
even before they are added to the system).
One result from this can be log spoofing, since the interface name is
passed to logging functions unmodified. The string could contain control
characters or newlines, which can manipulate the log.
In DbusCommon.add_interface() the possibly
crafted interface name is added to the to-be-generated JSON configuration via
the out() method. While we did not verify whether this works in practice, a
local attacker could attempt to largely control the JSON configuration passed
to nftables, by skillfully embedding additional JSON configuration in the
interface parameter.
We were worried that this could even lead to arbitrary code execution by
abusing features of nftables like loading external files or plugin code, but
it turned out that there are no such features available in the nftables
configuration format.
umask used in Daemonize CodeFoomuuri contains optional support to daemonize itself. Normally this is done
by systemd and the code in question is not invoked. It contains
logic to set the daemon’s umask to 0, however, which is a bad
default, since applications or libraries which intend to foster user control of
the file mode of newly created files can pass modes like 0666 to open(),
rendering them world-writable.
Foomuuri does not contain any code paths that create new files, but the umask
setting is also inherited by child processes, for example. While we did not
think this was a tangible security issue in this form, we suggested to choose a
more conservative value here to prevent future issues.
We suggested the following fixes to upstream:
root only, maybe also to
members of a dedicated opt-in group. Alternatively Polkit could be used for
authentication of callers, which is more effort and complex, however.interface input parameter should be verified right from the
beginning of each D-Bus method to make sure that it does not contain
any whitespace or special characters and is not longer than IFNAMSIZ bytes
(which is currently 16 bytes on Linux).ProtectSystem=full to Foomuuri’s systemd services,
to prevent possible privilege escalation should anything go wrong at
the first line of defense.Upstream decided to implement Polkit authentication for Foomuuri’s D-Bus service and otherwise followed closely our suggestions:
interface parameter to prevent manipulation of the JSON configuration
data.umask used in the daemonize code
to a more conservative 0o022 setting, preventing world- or group-writable
files from coming into existence.ProtectSystem=full
directive to all Foomuuri systemd service units.All of the bugfixes are contained in version 0.31 of Foomuuri.
In agreement with upstream we assigned the following two CVEs corresponding to this report:
CVE-2025-67603: lack of client authorization allows arbitrary users to influence the firewall configuration (issue 3.1).
CVE-2025-67858: a crafted interface input parameter to D-Bus methods can
lead to integrity loss of the firewall configuration or further unspecified
impact by manipulating the JSON configuration passed to nft
(issue 3.2).
We reported these issues to the upstream developer on 2025-12-11, offering coordinated disclosure. We soon got a reply and discussed the details of the non-disclosure process. Upstream quickly shared patches with us for review and we agreed on the final patches already on 2025-12-19. In light of the approaching Christmas season we agreed on a publication date of 2026-01-07 for general disclosure.
We want to thank the upstream author for the prompt reaction and cooperation in fixing the issues.
| 2025-12-11 | We contacted the Foomuuri developer by email providing a detailed report about the D-Bus related findings and offered coordinated disclosure. |
| 2025-12-12 | The upstream author confirmed the issues, agreed to coordinated disclosure and asked us to assign CVEs the way we suggested them. 2026-01-07 was suggested for publication date. |
| 2025-12-15 | We discussed some additional technical details like the umask issue and the question of whether arbitrary code execution could result from the ability to control the JSON configuration passed to nft. |
| 2025-12-18 | Upstream shared with us a first version of patches for the issues we reported. The patches for minor issues and hardening were already published on GitHub at this point. |
| 2025-12-19 | We provided feedback on the patches, suggesting minor improvements. |
| 2025-12-19 | With the fixes ready we discussed whether earlier publication would make sense, but we agreed to stick to the date of 2026-01-07 to accommodate the Christmas holiday season. |
| 2026-01-07 | Upstream release v0.31 was published. |
| 2026-01-07 | Publication of this report. |
TLP is a utility for saving laptop battery power when running Linux (note: the TLP acronym has no special meaning). In version 1.9.0 of TLP a profiles daemon similar to GNOME’s power profiles daemon has been added to the project, providing a D-Bus API for controlling some of TLP’s settings.
Our SUSE TLP package maintainer asked us for a review of the changes contained in the new TLP release, leading us to discover issues in the Polkit authentication logic used in TLP’s profiles daemon, which allow a complete authentication bypass. While looking into the daemon we also found some additional security problems in the area of local Denial-of-Service (DoS).
We reported the issues to upstream in December and performed coordinated disclosure. TLP release 1.9.1 contains fixes for the issues described below. This report is based on TLP 1.9.0.
The next section provides a quick overview of the TLP power daemon. Section 3 discusses the security issues we discovered in detail. Section 4 looks into the CVEs we assigned. Section 5 provides a summary of the coordinated disclosure process we followed for these findings.
The new TLP power daemon is implemented in a Python script of moderate
size. The daemon runs with full root privileges and accepts
D-Bus client connections from arbitrary users. For authorization of clients a
Polkit policy defines a couple of actions which are
checked in the daemon’s _check_polkit_auth() function.
Some of these actions are allowed for local users in an active session without
providing further credentials, others require admin credentials.
The check_polkit_auth() function relies on Polkit’s
“unix-process” subject in an unsafe way. The function obtains the caller’s PID
and passes this information to the Polkit daemon for authorization, which is
inherently subject to a race condition: at the time the Polkit daemon looks up
the provided PID, the process can already have been replaced by a different
one with higher privileges than the D-Bus client actually has.
As a result of this, the Polkit authorization check in the TLP power daemon can be bypassed by local users, allowing them to arbitrarily control the power profile in use as well as the daemon’s log settings.
This is a well-known issue when using the “unix-process” Polkit subject which was assigned CVE-2013-4288 in the past. For this reason the subject has been marked as deprecated in Polkit. The “unix-process” subject is seeing new use these days, however, when combined with the use of Linux PID file descriptors, which are not affected by the race condition.
We suggested to upstream to switch to Polkit’s D-Bus “system bus name” subject instead, which is a robust way to authenticate D-Bus clients based on the UNIX domain socket the client uses to connect to the bus. This is what upstream did in commit 08aa9cd.
The D-Bus methods “HoldProfile” and “ReleaseProfile” can be used by locally logged-in users without admin authentication and allow to establish a “profile hold”, preventing the profile from being automatically switched until it is released again.
The “HoldProfile” method returns a cookie value to the caller which needs to be presented to the “ReleaseProfile” method again to release it. This cookie value is a simple integer which starts counting at zero and is incremented for each call to “HoldProfile”. This makes the cookie value predictable and allows other, unrelated users or applications to release an active profile hold by trying to guess the cookie value in use.
We suggested to upstream to make the cookie value unpredictable by generating a random number. This is what upstream did in commit a88002e.
cookie Parameter in “ReleaseProfile” Method Leads to Unhandled ExceptionAs described in the previous section, the “ReleaseProfile” D-Bus
method expects an integer cookie parameter as input.
The Python D-Bus framework used to implement the method allows clients to pass
non-integer types as cookie, however, which causes an exception to be thrown
in the daemon. This does not lead to the daemon exiting, however, since the
framework catches the exception.
The issue can be reproduced via the following command line:
user$ dbus-send --system --dest=org.freedesktop.UPower.PowerProfiles \
--type=method_call --print-reply /org/freedesktop/UPower/PowerProfiles \
org.freedesktop.UPower.PowerProfiles.ReleaseProfile string:test
Error org.freedesktop.DBus.Python.ValueError: Traceback (most recent call
last):
File "/usr/lib/python3.13/site-packages/dbus/service.py", line 712, in
_message_cb
retval = candidate_method(self, *args, **keywords)
File "/usr/sbin/tlp-pd", line 223, in ReleaseProfile
cookie = int(cookie)
ValueError: invalid literal for int() with base 10: dbus.String('test')
While this is not strictly a security issue, we still suggested to make the
daemon more robust by actively catching type mismatch issues for the cookie
input parameter. Upstream followed this suggestion and implemented it in the
same commit as above which introduces unpredictable
cookie values.
The profile hold mechanism described in section
3.2 allows local users in an active session
to create an unlimited number of profile holds without admin authentication.
This can lead to resource exhaustion in the TLP power daemon, since an integer
is entered into a Python dictionary along with arbitrary strings reason and
application_id which are also supplied by the client. This API thus
offers Denial-of-Service attack surface.
We found a similar issue in GNOME’s power profile daemon some years ago, but GNOME upstream disagreed with our analysis at the time, which is why SUSE distributions are applying a custom patch to limit the number parallel profile holds.
We asked upstream whether there are any valid use cases for supporting a large number of profile holds in parallel, and it turns out that the typical use case is only to support a single profile hold at any given time. Thus upstream agreed to restrict the number of profile holds to a maximum of 16, which is implemented in commit 6a637c9.
We assigned CVE-2025-67859 to track issue 3.1 (Polkit authentication bypass). Issues 3.2 (predictable cookie values) and 3.4 (unlimited number of profile holds) would formally also justify CVE assignments; their severity is low, however, and we agreed with upstream to focus on the main aspect of the Polkit authentication bypass.
We reached out to the upstream author on December 16 with details about the issues and offered coordinated disclosure. Upstream confirmed the issues and accepted coordinated disclosure. We discussed patches and further details over the course of the following two weeks. Due to the approaching Christmas holiday season we decided to set the general publication date to January 7.
We want to express our thanks to the TLP upstream author for the smooth cooperation in handling these issues.
| 2025-12-16 | We reached out to the upstream developer by email providing a detailed report and offered coordinated disclosure. |
| 2025-12-17 | We received a reply discussing details of the report. Coordinated disclosure was established with a preliminary publication date set to 2026-01-27. |
| 2025-12-20 | We received a set of patches from upstream for review. 2026-01-07 was suggested as new publication date. |
| 2025-12-23 | We provided positive feedback on the patches and agreed to the new publication date. We also pointed out the additional problem of the unlimited number of profile holds (issue 3.4). |
| 2025-12-25 | We received a follow-up patch from upstream limiting the number of profile holds. |
| 2025-12-29 | We reviewed the follow-up patch and provided positive feedback to upstream. |
| 2025-01-07 | Upstream published bugfix release 1.9.1 as planned. |
| 2025-01-07 | Publication of this report. |
Smb4KMountHelper::mount()
Smb4KMountHelper::unmount()
smb4k is a KDE desktop related utility which allows unprivileged mounting of Samba/CIFS network shares. The SUSE security team reviewed its privileged KAuth helper component already in 2017 which led to the discovery of CVE-2017-8422 (general KAuth authentication bypass) and CVE-2017-8849 (local root exploit via smb4k mount helper).
This September we were asked to reconsider smb4k for inclusion in openSUSE Tumbleweed. The resulting review showed that the mount helper still lacks input validation, is affected by race conditions and has a bug in its existing verification logic. This leads to local attack vectors which allow Denial-of-Service or even a local root exploit.
Many Linux distributions and also some BSDs are potentially affected by the issues described in this report. We offered coordinated disclosure to upstream and the maximum 90 days non-disclosure period was fully spent to arrive at a patch which addresses all the issues. This patch is found in commit 0dea60194a, which is part of the 4.0.5 bugfix release of smb4k.
The following section provides a short overview of the privileged mount helper. Section 3 looks into the problems found in the helper’s mount method. Section 4 in turn looks into the issues found in the helper’s unmount method. Section 5 contains further remarks on the helper’s code quality and security concerns. Section 6 discusses the fixes we suggested to upstream to address the issues. Section 7 gives details about the bugfix which was finally implemented by upstream. Section 8 suggests possible workarounds that can be applied to avoid the issues found in this report. Section 9 provides reproducers for the issues.
This report is based on smb4k release 4.0.4.
The problematic privileged mount helper component of smb4k is relatively small
and can be found in the file smb4kmounthelper.cpp. The
helper runs with full root privileges and implements two KAuth actions
accessible via D-Bus: mounting and unmounting a network share. Both actions
are allowed for local users in active sessions without authentication, based
on the Polkit yes setting.
Smb4KMountHelper::mount()The helper does not impose any restrictions on the target directory
where the desired Samba share will be mounted. This means the share can
also be mounted over /bin, for example. Should the client have control
over the contents of the network share, then this allows for a local root
exploit by placing crafted binaries e.g. for /bin/bash on the share, which
are bound to be executed by privileged processes at some point.
If the share’s content cannot be controlled by the attacker, then this serves as a local Denial-of-Service attack vector, as vital system programs will become inaccessible.
To fix this, we suggest to only allow mounting of network shares in a pre-defined location which is not controlled by unprivileged users.
mount.cifsThe client can specify arbitrary additional command line arguments in the
mh_options parameter, which will be passed to the mount.cifs
program. The command line constructed by the mount helper
looks like this:
/sbin/mount.cifs <URL> <mountpoint> <options>...
All of these arguments, except for the path to the mount.cifs program
itself, are actually controlled by the client. It is not the generic mount
program which is invoked here, otherwise the client could already perform
arbitrary mounts in the system. Instead the attacker is restricted to what the
special-purpose mount.cifs binary provides.
The mount.cifs program supports a plethora of mount
options. Investigating the effect of each one would go
beyond the scope of this report. There is one simple privilege escalation
vector, however: passing filemode=04777,uid=0 to the command line results in
every file on the network share mount receiving setuid-root permissions. If
the content of the network share is controlled by the attacker, then this can
easily be used to introduce an attacker-controlled setuid-root program into
the system. This would then allow for a local root exploit even if issue
3.1) would be fixed.
Other mount.cifs options like port=<port> could be used to direct the
kernel to a CIFS server controlled by the attacker itself, listening on an
unprivileged port on localhost. This way a local attacker could provide the
necessary crafted network share for executing the exploits described in this
report on its own, without relying on external network resources.
To fix this, we suggest to restrict the mh_options to a whitelist of allowed
parameters, and also verify the options’ values in case they can contain
problematic settings.
KRB5CCNAME Environment Variable Passed To mount.cifsThe client can provide an arbitrary path in the mh_krb5ticket parameter;
the mount helper will place this path into the KRB5CCNAME environment
variable for the mount.cifs child process. This is
to allow use of the client’s Kerberos credentials for mounting the network
share.
The client can pass a path pointing to file system locations normally not
accessible to it. In a multi-user scenario this would allow, for
example, to hijack another user’s Kerberos credentials, by passing a path to
the credentials cache of the other user. It might also lead to information
leaks of files like /etc/shadow, should mount.cifs output file content to
the system logs or on stderr (the output of which is returned to the client
via D-Bus).
Furthermore, this path could be used for file existence tests or for a local
Denial-of-Service attack (by pointing to special files like /dev/zero or a
named FIFO pipe).
To fix this, we recommend not to pass a path, but an already open file descriptor from the client to the helper, to avoid the opening of arbitrary files with root privileges.
Smb4KMountHelper::unmount()return Statement on Mount Path Verification FailureThis is similar to issue 3.1) above
regarding mounting. In smb4kmounthelper.cpp line
177 there is an if block that acts on the
situation when the mh_mountpoint path supplied by the client does not match
any of the available Samba mounts returned from
KMountPoint::currentMountPoints().
The problem is that this if block only sets an error message, but does not
actually terminate the function execution with return. This means the
verification is ineffective and local users can unmount arbitrary file systems
despite the check.
This is a major local Denial-of-Service attack vector, which can lead to a complete system outage. In some special contexts it might even allow information leaks or privilege escalation, when file system locations have been made inaccessible by mounting other file systems on top (we can imagine something like this e.g. in the context of container setups).
umountSimilar to issue 3.2) above, the privileged
helper forwards arbitrary command line parameters provided by the client in
mh_options to the command line of the umount program. This happens in
smb4kmounthelper.cpp line 187. Basically the umount
program will be invoked like this:
/sbin/umount <options>... <mount-point>
Assuming issue 4.1) would be fixed, the
<mount-point> parameter cannot be chosen arbitrarily by the client, but must
match an existing “cifs”, “smbfs” or “smb3” type mount path. As long as such a
mount path exists, the client can pass arbitrary additional mount points as
“options”, which will then be unmounted as well. This is a lighter variant of
issue 4.1), leading to local Denial-of-Service if the described pre-condition
is fulfilled.
Apart from this, umount offers various options that
can influence the way it operates. One option that sticks out is -N
--namespace ns, which causes the program to unmount the file system in an
arbitrary mount namespace. This could impact privileged processes, other
users’ containers or jailed processes.
To fix this, we suggest to restrict the mh_options to a whitelist of allowed
parameters.
KMountPoint::currentMountPoints()This is not directly an issue in smb4k itself, but an issue in the KIO
library which implements the KMountPoint API. During our
tests we used version v6.17.0 of this library.
The mount helper’s umount() function attempts to verify
the input path provided by the client by comparing it against current mounts
in the system as reported by the kernel. Only active “cifs”, “smbfs” and
“smb3” file system mounts are supposed to be unmounted. To this end the
current list of mounted file systems is obtained from
KMountPoint::currentMountPoints(KMountPoint::BasicInfoNeeded | KMountPoint::NeedMountOptions);
The implementation of currentMountPoints() relies on the libmount
library to retrieve a list of mount points. The
libmount library provides a proven implementation for safely parsing
files like /proc/self/mountinfo, which we reviewed ourselves a few years
ago and deemed robust. After safely obtaining the information from
libmount, the KIO library performs some actions on top, however, which
can lead to security relevant issues.
One minor issue is found in kmountpoint.cpp line 365, where
stat() is called on the target mount directory of each mount entry. This
potentially accesses untrusted paths, also from FUSE file systems, which could
in some cases cause a local Denial-of-Service if stat() blocks. Also, the
supposed mount point could be unmounted by the time the stat() call is
performed, allowing the path to point to an arbitrary file (also following
symbolic links), which would lead to incorrect information in the m_deviceID
field of the information returned by currentMountPoints().
Later on the code tries to “resolve GVFS mount points” in line
382. The resolveGvfsMountPoints()
function that implements this logic looks for mount
entries with “gvfsd-fuse” as source device name. For each of these mount
points the function will list the mount’s directory contents and look for
directory entries of the form <type>:<label>, where type refers to the
file system type that is expected to be found there. The function then
synthesizes additional mount entries from this information which will be
returned to the caller, appearing as fully-fledged regular mounts.
There are two problems with this. For one, these operations are all subject to
race conditions; the mount table entries can change at any time. Secondly,
there exists a common way for unprivileged users in Linux systems to create
mount points with arbitrary source device names. This is the fusermount
setuid-root utility, which is used for mounting FUSE file systems. Local users
can create a fake gvfsd-fuse mount point like this:
$ export _FUSE_COMMFD=0
$ mkdir $HOME/mnt
$ fusermount $HOME/mnt -ononempty,fsname=gvfsd-fuse
$ mount | tail -n1
gvfsd-fuse on /home/$USER/mnt type fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=100)
The default FUSE configuration prevents the root user from accessing
non-root controlled FUSE file systems. To overcome this limitation, an
attacker can perform the following steps:
gvfsd-fuse mount like shown above.unmount() logic in smb4k’s mount helper.$HOME/mnt after currentMountPoints() obtained the
mount information from libmount, but before it calls
resolveGvfsMountPoints().cifs:mymount. These directories can already be placed
there in advance, of course.currentMountPoints() function will return a
synthesized entry to the mount helper which lists a CIFS mount in the
unprivileged user’s $HOME/mnt/cifs:mymount.Using this approach, the verification step in the mount helper’s
unmount() function can be bypassed even if issues
4.1) and
4.2) would be fixed.
There are further potential issues in the KMountPoint logic, e.g. in
finalizeCurrentMountPoint() the source device name is resolved if the
KMountPoint::NeedRealDeviceName flag is passed by the caller. This
provides another opportunity for unprivileged FUSE mounts with fake
source device names to influence the outcome, e.g. to perform
file existence tests or otherwise trick the caller of the KIO library.
Due to these problems, the information obtained from
currentMountPoints() currently cannot be used to base security related
decisions on. Generally root should not perform these additional
queries at all. The library could check for geteuid() == 0 to prevent
the execution of this dangerous logic in privileged contexts.
For unprivileged applications we could imagine the addition of a flag like
KMountPoint::AllowUnsafe, which opts in to the problematic behaviour. Only
applications that are aware of the potential problems would then pass this
flag.
When we reported this, KDE security at first stated that the problems
described in this section would only affect smb4k and no other users of the
KMountPoint API. We found it questionable to consider a library’s API secure
only based on its supposed current users. Beyond that, even unprivileged
processes using this API might fall victim to other users in the system
crafting gvfsd mount information. One could argue that there is an issue in
the fusermount utility to begin with. The KMountPoint API is explicitly
processing a FUSE-based file system, however, and thus it should be prepared
to deal with the peculiarities this entails.
When we pointed out our continued concern to KDE security, it was suggested that we create an upstream issue, or ideally provide a bugfix ourselves. While we are happy to help where we can, the issue at hand is a larger API design topic, and we believe it should be dealt with carefully by the responsible upstream developers, allowing them also to learn from this experience. For this reason we only created the upstream issue, as was suggested to us.
Even if all the other issues discussed in this section would be fixed, the
current mount helper code allows to unmount arbitrary Samba shares, no matter
if they have been originally mounted by smb4k itself (for the same user or a
different one), or by other components in the system (e.g. via a fixed entry
in /etc/fstab).
Similarly to issue 3.1) above, we suggest to restrict smb4k mounts to a pre-defined location not controlled by unprivileged users to address this issue.
mh_command Client ParameterBoth helper actions compare an arbitrary path supplied by the client in
mh_command to the trusted “mount” or “unmount” program path returned
from findMountExecutable() or findUmountExecutable(), respectively. This
is odd. It seems this comparison is a remnant from the attempted fix of
CVE-2017-8849. This is superfluous logic that increases the complexity of both
client and helper unnecessarily and can cause confusion, at best.
The helper should choose the trusted mount program on its own and stop
considering the mh_command parameter at all.
There is a redundant check for online network interfaces in smb4kmounthelper.cpp line 38 and line 205. This code should be placed into a separate function instead, to avoid code duplication and to increase readability.
This online check is also highly heuristic, and it might be possible for unprivileged users to influence its outcome e.g. by creating unprivileged pseudo network devices that appear to be online.
mount.cifs and umount Follow Symbolic LinksBoth mount.cifs and umount follow symbolic links in path arguments. This
means that even if the mount helper would try to verify a path pointing to a
client-controlled location, this could be replaced with a symbolic link
by the time the actual mount.cifs or umount utility runs, and the mount
logic would then operate on a completely different location than expected by
the helper.
Apart from the individual suggestions mentioned in the context of the issues above, we believe the range and severity of the issues uncovered shows that a major redesign of the mount helper utility is necessary to address all the problems in a robust way.
Here are some suggestions regarding a larger redesign:
/mounts/smb4k, only controlled by
root, should be used for these purposes. Some form of tracking which mount
belongs to which user would be needed (e.g. giving ownership of the mount to
the client that requested it). This is more like udisks
solves the problem of mounting devices on user request.mount.cifs or umount won’t work securely. A more abstract interface with
well-defined settings for mounting or unmounting would help to restrict the
degrees of freedom that a client has. This would also improve the decoupling
of the helper’s interface from the concrete implementation, this way the
helper could e.g. change the implementation to call the mount() and
umount() system calls directly, instead of going through the mount
utilities.During the course of a month we discussed various versions of patches with the smb4k upstream developer, until we arrived at a workable patch just in time for publication of this report after the 90 days maximum embargo period we offered. The main aspects of the bugfix are as follows:
mount and unmount the options passed by the client are now more
closely scrutinized, and only settings present in a whitelist of options are
allowed anymore.filemode mount option, which is still basically supported, is now
checked to make sure no special file bits are present.uid and gid mount options can only be set to the UID/GID of the
caller, not to arbitrary IDs anymore./run/smb4k. This way, unprivileged users can no longer place symlinks in
the mount destination paths. Mounts are placed in per-UID subdirectories
such that different clients cannot influence each other’s mounts anymore.KMountPoint API is no longer used and has been replaced by
Qt’s QStorageInfo API. Formally the investigation of existing mount points
would no longer be necessary at all with the trusted mount tree location,
but the upstream developer preferred to keep this extra verification step
for the time being.We want to express our thanks to Alexander Reinholdt, the smb4k upstream developer, for cooperating with us and finishing the patch in time for publication. This way a series of long-standing issues in smb4k could finally be addressed.
If the upstream bugfix cannot be used right away, the following suggestions can be considered to remove the attack surface described in this report:
auth_admin. This way the problematic logic can only be
reached by already privileged users. This contradicts the original purpose of
smb4k, however, to allow unprivileged mounts and unmounts of network shares.smb4k. Coupled with a security disclaimer, this would allow
users that really want to use this feature to opt-in.The KAuth D-Bus interface cannot easily be invoked via utilities like gdbus,
because it expects a serialized QVariantMap as input. We offer two C++
programs which can be used to perform standalone tests of smb4k’s mount helper
API for the purposes of reproducing the attack vectors described in this
report, smb4k_mount.cpp and
smb4k_unmount.cpp. There are comments in the
source code of the reproducers that explain how to compile and use them.
Formally the findings in this report could justify a large count of CVEs, but we decided to condense them into the two main aspects that result from the issues:
When the end of the 90 days maximum non-disclosure period we offered upstream approached, due to lack of feedback from KDE Security, we assigned these CVEs as we originally suggested them to upstream.
We reached out to KDE security on September 11 and shared the full details about the issues described in this report, offering coordinated disclosure. For nearly the first two months of the maximum 90 days non-disclosure period, we had difficulties getting clear answers from KDE security about the expected publication date, whether they acknowledged the findings or even whether they wanted to practice coordinated disclosure at all.
We only saw some visible progress at the beginning of November, when the smb4k upstream developer joined the discussion and started developing bugfixes. The progress remained slow, however, due to limited resources on the end of the developer. Still, from this point onwards the discussion turned out helpful and cooperative, and we could finally see that the non-disclosure time was actually being put to use. We managed to agree on a bugfix that addresses all the issues only less than a week before the 90 days maximum embargo period would be reached.
In summary, we are not completely happy about how the coordinated disclosure developed in this case. We perceived an unwillingness on the end of KDE security to communicate and to help in coordinating the disclosure. We believe the issue could have been fixed faster by suggesting a workaround to users and by developing a bugfix in the open, with the help of the rest of the community.
| 2025-09-11 | We forwarded our report to security@kde.org, offering coordinated disclosure. |
| 2025-09-17 | We received acknowledgement of receipt from KDE security. |
| 2025-09-29 | Not having heard anything else from upstream, we asked at least for a confirmation of the issues described in the report and a formal decision whether coordinated disclosure was desired. We asked to get feedback until October 2, lest we would publish the information on our end. |
| 2025-10-01 | We got a reply from KDE security that they were working on the issue, without answering our questions. We replied again and tried to clarify that we did not intend to put time pressure on upstream, but would like to clearly setup the coordinated disclosure process. |
| 2025-10-02 | We got a short reply that they could not give us an expected publication date, repeating again that they were working on the issue. Our questions pertaining the process still remained unanswered. We once more explained that we would like to be involved in reviewing potential bugfixes where we could offer our help, and that we would like to avoid non-disclosure time passing without any visible progress. |
| 2025-10-07 | KDE security informed us that the fix was moving forward without giving further details. |
| 2025-11-07 | The smb4k developer, Alexander Reinholdt, contacted us directly sharing a first batch of suggested bugfixes. |
| 2025-11-12 | We provided detailed feedback on the security relevant part of the patch, pointing out various problems that remained, and new problems that got introduced. |
| 2025-11-12 | KDE security chimed in about the KMountPoint topic, stating that smb4k would be the only privileged component using this API. |
| 2025-11-13 | We replied to KDE security explaining in more detail the remaining concerns we had regarding the KMountPoint API. |
| 2025-11-16 | The smb4k developer thanked us for the review of the patch, and sent back detailed comments on our input. He told us he would be working on a follow-up patch set. |
| 2025-11-26 | The smb4k developer informed us that it would take still more time for him to provide the improved version of the patch. |
| 2025-11-26 | We thanked the developer for his continued effort, but also reminded all participants that the end of the 90 days maximum non-disclosure period we offered was approaching in two weeks. We suggested the alternative of publishing a temporary workaround instead (like increasing authentication requirements), should a full bugfix be out of reach within the remaining time. We also suggested to involve the distros mailing list at this time, to give other Linux and BSD distributions a chance to prepare before general publication of the report. |
| 2025-11-27 | On the topic of the KMountPoint API, KDE security clarified that they ideally would like a merge request from us addressing our concerns. |
| 2025-11-28 | We assigned the CVEs the way we initially suggested them to upstream, to provide them as additional information to the distros mailing list. We also shared the CVEs with upstream. |
| 2025-11-30 | The upstream developer shared an improved patch set with us. |
| 2025-12-01 | We sent another round of comments back to the upstream developer. The new patch was still lacking in a number of areas. |
| 2025-12-01 | We forwarded a draft of this report to the distros mailing list, announcing publication of the issues on 2025-12-10. We pointed out that no proper bugfix was available for sharing at this time. |
| 2025-12-03 | We received yet another version of the suggested patch from the upstream developer. |
| 2025-12-04 | This time we found no remaining security issues, agreed on the patch, but still commented on a couple of quality and style aspects. |
| 2025-12-04 | We forwarded the bugfix from the upstream developer to the distros mailing list. |
| 2025-12-05 | We asked the upstream developer to publish a bugfix release on 2025-12-10, which he agreed upon. |
| 2025-12-10 | Upstream published the bugfix release 4.0.5 as planned. |
| 2025-12-10 | Publication of this report. |
lightdm-kde-greeter is a KDE-themed greeter application for the lightdm display manager. At the beginning of September one of our community packagers asked us to review a D-Bus service contained in lightdm-kde-greeter for addition to openSUSE Tumbleweed.
In the course of the review we found a potential privilege escalation from the
lightdm service user to root which is facilitated by this D-Bus service,
among some other shortcomings in its implementation.
The next section provides a general overview of the D-Bus service. Section 3 discusses the security problems in the service’s implementation. Section 4 takes a look at the bugfix upstream arrived at.
This report is based on lightdm-kde-greeter release 6.0.3.
lightdm-kde-greeter includes a D-Bus service which enables regular users to configure custom themes to be used by the greeter application. The D-Bus service is implemented as a KDE KAuth helper service, running with full root privileges.
The helper implements a single API method, protected by
Polkit action org.kde.kcontrol.kcmlightdm.save, which requires
auth_admin_keep by default, i.e. users need to provide root credentials to
perform this action. The method takes a map of key/value pairs which allow to
fully control the contents of lightdm.conf and lightdm-kde-greeter.conf.
From a security point of view such a generic interface is sub-optimal, since the scope of the operation is not restricted to changing theme settings, but also allows to change all the rest of lightdm’s configuration, providing less control over who may do what in the system. From an application’s point of view this approach is understandable, however, as this makes it easy to support any future features.
Another Polkit action org.kde.kcontrol.kcmlightdm.savethemedetails is
declared in kcm_lightdm.actions, which is unused, maybe
a remnant of former versions of the project.
The problems in the D-Bus service start in helper.cc line 87, where we can find this comment:
// keys starting with "copy_" are handled in a special way, in fact,
// this is an instruction to copy the file to the greeter's home
// directory, because the greeter will not be able to read the image
// from the user's home folder
To start with it is rather bad API design to abuse the key/value map, which is supposed to contain configuration file entries, for carrying “secret” copy instructions. Even worse, in the resulting copy operation three different security contexts are mixed:
lightdm service user; the helper will copy the user-specified file
into a directory controlled by it.The helper performs this copy operation with full root privileges without
taking precautions, reading input data from one unprivileged context and
writing it into another unprivileged context. This is done naively using
the Qt framework’s QFile::copy() and similar APIs, leading to a range of
potential local attack vectors:
/etc/shadow, which will then become public in /var/lib/lightdm)./var/lib/lightdm/.../<theme>, thus the lightdm user can place
symlinks there which will be followed).If this action would ever be set to yes Polkit authentication requirements,
then this would be close to a local root exploit. Even in its existing form it
allows the lightdm service user to escalate privileges to root.
Interestingly these problems are quite similar to issues in sddm-kcm6, which
we covered in a previous blog post.
We suggested the following changes to upstream to address the problems:
root is already avoided.lightdm, a privilege drop to
the lightdm service user should be performed to avoid any symlink attack
surface.We are happy to share that the upstream maintainer of lightdm-kde-greeter
followed our suggestions closely and coordinated the changes with us before
the publication of the bugfix. With these changes, this KAuth helper is now
kind of a model implementation which can serve as a positive example for other
KDE components. Upstream also performed some general cleanup, like the removal
of the unused savethemedetails Polkit action from the repository.
Upstream released version 6.0.4 of lightdm-kde-greeter which contains the fixes.
In agreement with upstream, we assigned CVE-2025-62876 to track the lightdm
service user to root privilege escalation aspect described in this report.
The severity of the issue is low, since it only affects defense-in-depth (if
the lightdm service user were compromised) and the problematic logic can
only be reached and exploited if triggered interactively by a privileged user.
We reported these issues to KDE security on 2025-09-04 offering coordinated disclosure, but we initially had difficulties setting up the process with them. Upstream did not clearly express the desire to practice coordinated disclosure, no (preliminary) publication date could be set and no confirmation of the issues was received.
Things took a turn for the better when a lightdm-kde-greeter developer contacted us directly on 2025-10-16 and the publication date and fixes were discussed. The ensuing review process for the bugfixes was very helpful in our opinion, leading to a major improvement of the KAuth helper implementation in lightdm-kde-greeter.
| 2025-09-04 | We received the review request for the lightdm-kde-greeter D-Bus service. |
| 2025-09-10 | We privately reported the findings to KDE security. |
| 2025-09-17 | We received an initial reply from KDE security stating that they would get back to us. |
| 2025-09-29 | We asked for at least a confirmation of the report and a rough disclosure date, but upstream was not able to provide this. |
| 2025-10-01 | KDE security informed us that an upstream developer planned to release fixes by mid-November. |
| 2025-10-16 | An upstream developer contacted us to discuss the publication date, since the bugfixes were ready. |
| 2025-10-20 | We asked the developer to share the bugfixes for review. |
| 2025-10-21 | The developer shared a patch set with us. |
| 2025-10-24 | We agreed on 2025-10-31 for coordinated disclosure date. |
| 2025-10-28 | After a couple of email exchanges discussing the patches, upstream arrived at an improved patch set. We suggested to assign a CVE for the ligthdm to root attack surface. |
| 2025-10-29 | We assigned CVE-2025-62876. |
| 2025-11-03 | We asked when the bugfix release would be published, with the disclosure date already passed. |
| 2025-11-03 | Upstream agreed to publish on the same day. |
| 2025-11-03 | Upstream released version 6.0.4 containing the bugfixes. We published our Bugzilla bug on the topic. |
| 2025-11-13 | Publication of this report. |
scx_loader D-Bus ServiceThe scx project offers a range of dynamically loadable
custom schedulers implemented in Rust and C, which make use of the Linux
kernel’s sched_ext feature. An optional D-Bus service called scx_loader
provides an interface accessible to all users in the system, which allows to
load and configure the schedulers provided by scx. This D-Bus service is
present in scx up to version v1.0.17. As a response to this report,
scx_loader has been moved into a dedicated repository.
A SUSE colleague packaged scx for addition to openSUSE Tumbleweed, and the D-Bus service it contained required a review by our team. The review showed that the D-Bus service runs with full root privileges and is missing an authentication layer, thus allowing any user to nearly arbitrarily change the scheduling properties of the system, leading to Denial-of-Service and other attack vectors.
Upstream declined coordinated disclosure for this report and asked us to handle it in the open right away. In the discussion that followed, upstream rejected parts of our report and presented no clear path forward to fix the issues, which is why there is no bugfix available at the moment.
Section 2 provides an overview of the scx_loader D-Bus
service and its lack of authentication. Section 3 takes
a look into problematic command line parameters which can be influenced by
unprivileged clients. Section 4 looks into attempts to
achieve a local root exploit using the scx_loader API. Section
5 lists affected Linux distributions. Section
6 discusses possible approaches to fix the issues
found in this report. Section 7 takes a look at the upstream
efforts to fix the issues.
This report is based on version 1.0.16 of scx.
scx_loader D-Bus ServiceThe scx_loader D-Bus service is implemented in Rust
and offers a completely unauthenticated D-Bus interface on the system bus. The
upstream repository contains configuration files and documentation
advertising this service as suitable to be automatically
started via D-Bus requests. Thus arbitrary users in
the system (including low privilege service users or even nobody) are
allowed to make unrestricted use of the service.
The service’s interface offers functions to start, stop or switch between a number of scx schedulers. The start and switch methods also offer to specify an arbitrary list of parameters which will be directly passed to the binary implementing the scheduler.
Every scheduler is implemented in a dedicated binary and found e.g. in
/usr/bin/scx_bpfland for the bpfland scheduler. Not all schedulers that are
part of scx are accessible via this interface. The list of schedulers
supported by scx_loader in the reviewed version is:
scx_bpfland scx_cosmos scx_flash scx_lavd
scx_p2dq scx_tickless scx_rustland scx_rusty
We believe the ability to more or less arbitrarily tune the scheduling behaviour of the system already poses a local Denial-of-Service (DoS) attack vector that might even make it possible to lock up the complete system. We did not look into a concrete set of parameters that might achieve that, but it seems likely, given the range of schedulers and their parameters made available via the D-Bus interface.
The ability to pass arbitrary command line parameters to any of the supported scheduler binaries increases the attack surface of the D-Bus interface considerably. This makes a couple of concrete attacks possible, especially when the scheduler in question accepts file paths as input. Apart from parameters that influence scheduler behaviour, all schedulers offer the generic “Libbpf Options”, of which the following four options stick out in this context:
--pin-root-path <PIN_ROOT_PATH> Maps that set the 'pinning' attribute in their definition will have
their pin_path attribute set to a file in this directory, and be
auto-pinned to that path on load; defaults to "/sys/fs/bpf"
--kconfig <KCONFIG> Additional kernel config content that augments and overrides system
Kconfig for CONFIG_xxx externs
--btf-custom-path <BTF_CUSTOM_PATH> Path to the custom BTF to be used for BPF CO-RE relocations. This custom
BTF completely replaces the use of vmlinux BTF for the purpose of CO-RE
relocations. NOTE: any other BPF feature (e.g., fentry/fexit programs,
struct_ops, etc) will need actual kernel BTF at /sys/kernel/btf/vmlinux
--bpf-token-path <BPF_TOKEN_PATH> Path to BPF FS mount point to derive BPF token from. Created BPF token
will be used for all bpf() syscall operations that accept BPF token
(e.g., map creation, BTF and program loads, etc) automatically within
instantiated BPF object. If bpf_token_path is not specified, libbpf will
consult LIBBPF_BPF_TOKEN_PATH environment variable. If set, it will be
taken as a value of bpf_token_path option and will force libbpf to
either create BPF token from provided custom BPF FS path, or will
disable implicit BPF token creation, if envvar value is an empty string.
bpf_token_path overrides LIBBPF_BPF_TOKEN_PATH, if both are set at the
same time. Setting bpf_token_path option to empty string disables
libbpf's automatic attempt to create BPF token from default BPF FS mount
point (/sys/fs/bpf), in case this default behavior is undesirable
libbpf is a userspace support library for BPF programs found in the Linux source tree. The following sub-sections take a look at each of the attacker-controlled paths passed to this library in detail.
--pin-root-path OptionThe --pin-root-path option potentially causes libbpf to create the
parent directory of this path in
bfp_object__pin_programs(). We are not entirely
sure under which conditions the logic is triggered, however, and if these
conditions are controlled by an unprivileged caller in the context of the
scx_loader D-Bus API.
--kconfig OptionThe file found in the --kconfig path is completely read into memory in
libbpf_clap_opts.rs line 91. This makes
a number of attack vectors possible:
/dev/zero leads to an out of memory
situation in the selected scheduler binary./etc/shadow causes the scheduler binary to
read in the private data. We did not find a way for this data to leak out
into the context of an unprivileged D-Bus caller, however. This technique
still allows to perform file existence tests in locations that are normally
not accessible to unprivileged users.The following command line is an example reproducer which will cause the
scx_bpfland process to consume all system memory until it is killed by
the kernel:
user$ gdbus call -y -d org.scx.Loader -o /org/scx/Loader \
-m org.scx.Loader.SwitchSchedulerWithArgs scx_bpfland \
'["--kconfig", "/dev/zero"]'
--btf-custom-path OptionThe --btf-custom-path option offers similar attack vectors as the
--kconfig option discussed above. Additionally, crafted binary symbol
information can be fed to the scheduler via this path, which will be processed
either by btf_parse_raw() or
btf_parse_elf() found in libbpf. This can lead to
integrity violation of the scheduler / the kernel, the impact of which we
cannot fully judge as we lack expertise in this low level area and did not
want to invest more time than necessary for the analysis.
--bpf-token-path OptionThe --bpf-token-path, if it refers to a directory, will be opened by
libbpf and the file descriptor will be passed to the
bpf system call like this:
bpf(BPF_TOKEN_CREATE, {token_create={flags=0, bpffs_fd=20}}, 8) = -1 EINVAL (Invalid argument)
This does not seem to achieve anything, however, because the kernel code rejects the caller if it lives in the initial user namespace (which the privileged D-Bus service always does). The path could maybe serve as an information leak to test file existence and type, if the behaviour of the scheduler “start” operation shows observable differences depending on the input.
With this much control over the command line parameters of many different scheduler binaries, which offer a wide range of options, we initially assumed that a full local root exploit would not be difficult to achieve. We tried hard, however, and did not find any working attack vector so far. It could be that we overlooked something in the area of the low level BPF handling regarding the attacker-controlled input files discussed in the previous section, however.
scx_loader is saved from a trivial local root exploit merely by the fact
that only a subset of the available scx scheduler binaries is accessible via
its interface. The scx_chaos scheduler, which is not among the schedulers
offered by the D-Bus service, supports a positional command line
argument referring to a “Program to run under the chaos
scheduler”. Would this scheduler be accessible via D-Bus, then unprivileged
users could cause user controlled programs to be executed with full root
privileges, leading to arbitrary code execution.
From discussions with upstream it sounds like the exclusion of schedulers like
scx_chaos from the D-Bus interface does not stem from security concerns, but
rather from functional restrictions, because some schedulers are not supported
in all contexts, or are not stable yet.
From our investigations and communication with upstream it seems that only
Arch Linux is affected by the problem in its default installation of scx.
Gentoo Linux comes with an ebuild for scx, but for some reason there is no
integration of scx_loader into the init system and also the D-Bus autostart
configuration file is missing. Thus it will only be affected if an admin
manually invokes the service.
Otherwise we did not find a packaging of scx_loader on current Fedora Linux,
Ubuntu LTS or Debian Linux. Due to the outcome of this review we never allowed
the D-Bus service into openSUSE, which is therefore also not affected.
A quick fix for the worst aspects of the issue would be to restrict the
D-Bus configuration in org.scx.Loader.conf to allow
access to the interface only for members of a dedicated group like scx. This
at least prevents random unprivileged users from abusing the API.
We offer a patch for download which does exactly this.
By integrating Polkit authentication, the use of this interface can be
restricted to physically present interactive users. Even in this case we
suggest to restrict full API access to users that can authenticate as admin,
via Polkit’s auth_admin_keep setting. Read-only operations can still be
allowed without authentication.
The individual methods offered by the scx.Loader D-Bus service should not allow to perform actions beyond the intended scope, even if a caller would have authenticated in some form as outlined in the previous sections.
To this end, dangerous parameters for schedulers should either be rejected (e.g. by enforcing a whitelist of allowed parameters) or verified (e.g. by determining whether a provided path is only under control of root and similar checks).
Regarding input files, the client ideally should not pass path names at all, but send file descriptors instead, to avoid unexpected surprises and the burden of verifying input paths in the privileged D-Bus service.
The systemd service for scx_loader could make use of various hardening
options that systemd offers (like ProtectSystem=full), as long as these
do not interfere with the functionality of the service. This would
prevent more dangerous attack vectors from succeeding if the first line of
defense fails.
Upstream showed a reluctant reaction to the report
we provided in a GitHub issue, rejecting parts of our
assessment. An attempt to introduce a Polkit authentication
layer based on AI-generated code was abandoned quickly,
and upstream instead split off the scx_loader service into a new
repository to separate it from the scx core project. Our
original GitHub issue has been closed, and we cloned it
in the new repository to keep track of the issue.
Downstream integrators of scx_loader can can limit access to the D-Bus
service to members of an scx group by applying the patch we offer in the
Suggested Fixes section. This way access to the
problematic API becomes opt-in, and is restricted to more privileged users
that actually intend to use this service.
We suggested to upstream to assign at least one cumulative CVE to generally cover the unauthenticated D-Bus interface aspect leading to local DoS, potential information disclosure and integrity violation. We offered to assign a CVE from the SUSE pool to simplify the process.
Upstream did not respond to this and did not clearly confirm the issues we raised, but rather rejected certain elements of our report. For this reason there is currently no CVE assignment available.
| 2025-09-30 | We contacted one of the upstream developers by email and asked for a security contact of the project, since none was documented in the repository. |
| 2025-09-30 | The upstream developer agreed to handle the report together with a fellow developer of the project. |
| 2025-09-30 | We shared a detailed report with the two developers. |
| 2025-10-02 | After analysis of the report, the upstream developer suggested to create a public GitHub issue, which we did. |
| 2025-10-03 | An upstream developer responded to the issue rejecting various parts of our report. |
| 2025-10-28 | With some delay we provided a short reply, pointing out that the rejections seem to miss the central point of the change of privilege which is taking place. |
| 2025-10-28 | Upstream created a pull request based on AI-generated code to add an authentication layer to the D-Bus service. |
| 2025-10-28 | Upstream closed the unmerged pull request shortly after. The discussion sounded like upstream no longer intends to support the scx_loader D-Bus service in this repository. |
| 2025-11-03 | We provided a more detailed reply to the issue discussion. |
| 2025-11-04 | Upstream closed the GitHub issue and split off a dedicated repository for scx_loader |
| 2025-11-06 | We cloned the original issue in the new repository |
| 2025-11-06 | Publication of this report. |
OpenSMTPD is an implementation of the server-side SMTP protocol offered by the OpenBSD project. A few months ago a SUSE colleague started packaging it for openSUSE Tumbleweed, which led to a code review of the package.
While looking into a local API offered by OpenSMTPD we discovered a trivial local Denial-of-Service (DoS) attack vector which allows unprivileged users to cause the shutdown of all smtpd services. The full details about the issue follow in section 2. Some additional remarks about setuid-root and setgid utilities contained in OpenSMTPD are found in section 3. A quick survey of the network-facing code of OpenSMTPD is provided in section 4.
Note that two source code repositories for OpenSMTPD exist. The most up-to-date code is found in the OpenBSD CVS repository, while the portable version is found on GitHub. The portable version offers cross platform support for various kinds of UNIX systems, including Linux and the other BSDs. This report is based on the portable OpenSMTPD version 7.7.0p0.
We reported the local DoS issue to upstream but did not get a response until two days before publication, due to communication issues. By now an upstream bugfix is available which will be part of a pending 7.8.0 release, but it seems an independent memory leak issue remains unaddressed.
OpenSMTPD contains the smtpctl program, which communicates with the smtpd:
control daemon instance via a UNIX domain socket in /var/run/smtpd.sock.
While looking into the protocol used for this purpose, we noticed a trivial
local Denial-of-Service attack vector affecting all of OpenSMTPD.
The UNIX domain socket smtpd.sock has file mode 0666 and is thus writable
for all users in the system, allowing anybody to create local connections
towards smtpd.
In the daemon’s code in mproc_dispatch() the
process exits via fatal() in case anything goes wrong while handling such a
UNIX domain socket connection. Two common error situations leading to this are
bad returns from readv() in ibuf_read() or a bad message
length value in the message header, which is detected in
imsg_parse_hdr(). Similar error conditions exist in
the msgbuf_read() call path which is used when file
descriptor passing is enabled on the connection (see
imsgbuf_read()).
As a result, sending a malformed message with a bad header length is enough
for a client to provoke the invocation of fatal() on the daemon side. Once
fatal() is called, the smtpd: control instance ends execution and causes
the whole smtpd instance to be shut down along with it.
We learned from upstream that the reason for the call to fatal() is that
smtpd.sock is used for two different purposes at the same time:
smtpd daemon instances.smtpctl program.The call to fatal() is made with the first kind of connections in mind.
These connections are established during startup, and if anything goes wrong
while processing data from other smtpd daemon instances, then a bug in
OpenSMTPD itself is assumed, and a shutdown of all daemon processes is a
viable course of action.
The second kind of connections was left unconsidered in this logic, thus
allowing unprivileged clients to trigger this code path which leads to the
local DoS. The upstream bugfix consequently consists
of an added if clause which excludes the second type of connections from the
call to fatal().
While looking into a possible bugfix for the DoS issue, we noticed a comment in the code, which points to unsolved cleanup issues, when processing a connection fails:
ibuf_read_process(struct msgbuf *msgbuf, int fd)
{
/* <<< SNIP >>> */
fail:
/* XXX how to properly clean up is unclear */
if (fd != -1)
close(fd);
return (-1);
}
This made us wonder, if the cleanup is unclear in error conditions, is it maybe also unclear during regular operation? After all, proper cleanup will be needed regardless of whether a connection ends gracefully or not. As it happens, the cleanup logic for a regular connection close and for an erroneous connection close indeed is equivalent in OpenSMTPD.
To this end, we tested what happens when a lot of UNIX domain socket
connections towards smtpd are created and closed in succession. The outcome
indeed is that the memory used by the smtpd: control instance
continuously grows. Thus it seems there is a memory leak present here as
well independently of the main issue described above. We did not analyze this
in more detail, but upstream is aware of the issue and is analyzing it on
their end.
This independent issue means that unprivileged clients can trigger the memory
leak in the smtpd: control daemon, even after applying the upstream
bugfix to fix the main issue in this report. The
impact will also be a local DoS, it will take a much longer time to execute
it, however, because the memory leak is small and in our tests only consumes
about 100 megabytes within half an hour. The next section describes a possible
temporary workaround to avoid this issue, as well.
We initially suggested a different patch to
address the local DoS issue, tightening the permissions of the
smtpd.sock UNIX domain socket. We wrongly assumed that there were no valid
use cases for non-root users connecting to this socket. Shortly before
publication we learned from upstream that there actually is a valid use case
for this scenario: non-root users can enqueue mail using the sendmail
interface, which makes use of this socket.
Even though our suggested patch causes a regression in this case, it reduces attack surface and provides protection against the memory leak described in the previous section. For some users of OpenSMTPD it can thus be a sensible option to use this patch if the described use case is not needed, at least until upstream provides a fix for the memory leak issue, as well.
We offer a simple Python script to reproduce the issue.
The script creates a connection towards smtpd.sock and sends an excessive
header length. If the reproducer works, the smtpd daemon processes will all
exit immediately.
In commit 3270e23a6eb, which first made its way into
version 7.7.0, major changes to the message parsing code have been introduced,
including the call to fatal(). Triggering the issue was easily possible in
our tests for all packages based on this version.
It is unclear if older versions might be affected by some variant of this issue as well. We only verified that the trivial reproducer does not work against version 7.6.0 of OpenSMTPD.
We verified that the issue affects the following systems, which all offer OpenSMTPD version 7.7.0:
On FreeBSD 14.2, where only the older version 7.6.0 of OpenSMTPD is available, we could not reproduce the issue.
Without a formal confirmation from upstream we were reluctant to assign a CVE for the issue. The case seemed clear-cut, however, and when we were asked to provide a CVE on the distros mailing list, we assigned CVE-2025-62875 and also communicated this to upstream.
When contact to upstream was established shortly before the publication of this report, upstream picked up this CVE and used it to document their bugfix.
Upstream already published the bugfix commit for the main issue in this report. The release of OpenSMTPD version 7.8.0 containing this bugfix is expected soon, and was already announced on the upstream mailing list.
The original reason for reviewing OpenSMTPD in the first place was the presence of setuid and setgid binaries in the package. The following sub-sections give a short summary of the outcome of the review.
/usr/libexec/opensmtpd/lockspool is a world-accessible setuid-root binary
which is used to synchronize parallel access to a user’s spool.
The lockspool code found in the OpenSMTPD portable release is quite complex and is based on some assumptions that might not hold true. This code can allow for a minor local DoS in multi-user scenarios. The OpenBSD CVS repository already contains a simplified locking algorithm which is not affected by this.
We reached out to upstream about this separately from the UNIX domain socket DoS issue. In this instance we quickly got a reply and upstream merged the change from the CVS repository into the OpenBSD portable repository. This change will be part of the OpenSMTPD 7.8.0 release. We backported the change into the openSUSE packaging of OpenSMTPD as well.
/usr/sbin/smtpctl is a world-accessible setgid binary operating in _smtpq
group context. The program uses these special group privileges to store mail
in the directory /var/spool/smtpd/offline, when the smtpd services are not
running.
The _smtpq group privileges are only used for this well defined purpose and
the extra privileges are also dropped as soon as they are no longer needed. We
found no issues in this aspect of the program.
After we found the local security issues described in this report, we thought it a good idea to also have at least a cursory look at the actual network-facing SMTP protocol parsing code found in OpenSMTPD. We could not find any tangible security issues in these parts, still here is a short summary of our impression of the code:
chroot jail, which reduces attack
surface.| 2025-09-15 | We reported the issue to security@openbsd.org, offering coordinated disclosure. We quickly got a short reply that the topic had been forwarded to the relevant people. |
| 2025-09-29 | After two weeks without a more detailed response, we sent a follow-up email asking for confirmation of the issue and if coordinated disclosure was desired, or not. We asked for a response until 2025-10-02, otherwise we would publish the finding on our own terms. |
| 2025-10-02 | Still without response, we decided to partially publish the issue by adding a patch to our packaging, which secures the UNIX domain socket permissions. |
| 2025-10-23 | We approached the distros mailing list to give a heads-up to other distributions about the issue. We suggested an embargo until 2025-10-31. |
| 2025-10-24 | A member of the distros mailing list asked for a CVE, so we decided to assign CVE-2025-62875 and also informed upstream about this and the ongoing embargo on the distros mailing list. |
| 2025-10-27 | We shared the suggested patch with the distros mailing list, which we initially had forgotten to do. |
| 2025-10-29 | An OpenSMTPD developer finally replied to our report, explaining that the information had been lost internally until now. Upstream confirmed the issue and informed us that a bugfix release was being prepared for 2025-11-03 at the latest. |
| 2025-10-30 | From further discussions with upstream we learned about the real intentions of the call to fatal() and about the regression caused by our suggested patch. We on the other hand informed upstream about the additional memory leak issue we stumbled upon. |
| 2025-10-31 | Upstream published its bugfix for the main issue. |
| 2025-10-31 | We updated our report with the latest information from upstream and published it. |
Autumn is already palpable for many of us these days and this means it is time to take a look back at what happened in our team during the summer months. We have not published any dedicated security reports during that time; instead we have all the more to cover in this edition of the spotlight series which discusses code review efforts that did not lead to major findings or otherwise did not qualify for a dedicated report.
This is also the first anniversary of the spotlight series, which we started in August 2024 with the first summer spotlight edition. We are happy to provide our readers with interesting content about the daily work in our team and are looking forward to more anniversaries to come.
In this issue we will cover a local root exploit we discovered in systemd
v258-rc4 before it became part of a stable release, problems
found in logrotate drop-in configuration files, changes
in D-Bus configuration files related to the GNOME version 49
release, and a follow-up code review of the Kea DHCP server
suite. Furthermore we found a symlink attack issue in
chronyc, proactively reviewed new Varlink
services developed by fellow SUSE engineers and discovered a
local privilege escalation issue in bash-git-prompt. Finally we
will talk about a problematic script used on Steam Deck
devices.
At the beginning of August one of our systemd maintainers asked us to review
D-Bus and Polkit API changes in a release candidate of
systemd 258. This major version update of systemd contains many API additions
e.g. in systemd-resolved, systemd-homed, systemd-machined and
systemd-nsresourced.
While looking into these changes we found an issue in systemd-machined. This
daemon can be used to manage virtual machines and containers alike.
In upstream commit adaff8eb35d a new Polkit
action “org.freedesktop.machine1.register-machine” has been added, which was
accessible to locally logged in users without authentication (Polkit yes
setting). The purpose of this new API is to allow users to register existing
containers with systemd-machined, that have been created by other means.
There exist two D-Bus methods which employ this Polkit action: “RegisterMachine” and “RegisterMachineWithNetwork”. Both accept a rather long list of parameters to describe the container which is supposed to be registered with the daemon. The following command line performs an example registration of a fake container:
$ gdbus call -y -d org.freedesktop.machine1 -o /org/freedesktop/machine1 \
-m org.freedesktop.machine1.Manager.RegisterMachineWithNetwork \
mymachine '[1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16]' myservice container \
$$ $PWD '[1, 2, 3]'
Among these parameters is the process ID (PID) of the leader process of the
container. In this example $$, i.e. the shell’s own PID, is passed as leader
PID. The release candidate implementation of systemd-machined failed to
verify whether this process is owned by the caller and an actual member of an
unprivileged user namespace belonging to a container.
The first problematic aspect we noticed about this was that systemd-machined
can send SIGTERM to the process group the given leader PID belongs to (e.g.
when registering a new container using the same name), allowing a trivial
local Denial-of-Service against arbitrary other processes. Far more
problematic was something else that we noticed: the unprivileged user was able
to enter a shell in such a crafted container, like this:
user$ machinectl shell mymachine
# full root privileges, this happens in the actual host's file system
container-root# touch /evil
Since the leader PID in this case is a process belonging to the host’s initial namespaces, the root shell for the “container” is actually a root shell in the host itself, giving full root privileges over the system.
This problem is found in all release candidates of systemd v258. We reported the problem privately to systemd security, and upstream developed bugfixes right away while still in the RC phase. The local root exploit was never present in any stable release version and thus end users are not affected by the problem, which is also why no CVE was assigned.
To address the issue, systemd-machined now verifies that the leader PID
specified by the client is actually owned by the caller. Furthermore the
authentication requirements for Polkit action “register-machine” have been
raised to auth_admin_keep even for local users.
While writing this very summary we noticed that one aspect of the issue had
been overlooked and was not fixed for the stable release: the verification of
the user namespace membership of the target process. Thus it is still possible
to gain a root shell this way, but only after authenticating as admin, which
means the caller already needs admin privileges to trigger the exploit. This
aspect has now been addressed for future releases by
upstream, which is important, because upstream intends to relax the
authentication requirements for this action to yes again at a later time.
With this version of systemd we are seeing a noticeable increase in complexity
in the implementation of a number of systemd components. In the area of
container management the complexity is pretty much by design, given the
intricacy of the different namespace mechanisms playing together, partly
under the control of unprivileged users. There is also the addition of
Varlink for Inter-Process-Communication, however, which
means that two different interfaces for D-Bus and Varlink now exist in parallel
for some services. This is also the case for systemd-machined.
While the D-Bus and Varlink interfaces usually call into shared functions for most of the business logic and share the same Polkit actions, there is necessarily a certain amount of redundancy in parsing and evaluation of input parameters. As a result this also increases the burden on code reviewers which now need to keep track of two different entry paths to the same logic.
We are not yet completely finished with reviewing all notable changes in systemd v258 but intend to complete the effort within the next couple of weeks. We are happy that our review efforts already prevented a local root exploit in software as widespread as systemd from ending up in production environments.
su <user> <group> DirectivesRecently we noticed that there exist a number of packages in openSUSE
Tumbleweed which trigger a
“logrotate-user-writable-log-dir” rpmlint
diagnostic. This diagnostic is emitted when a
package contains a logrotate drop-in configuration file (e.g. in
/etc/logrotate.d) which points the logrotate daemon to a log directory which
is controlled by non-root accounts, where it will operate with full root
privileges.
Operating as root in locations controlled by other users is generally very
difficult to get right and can easily lead to privilege escalation from a
service user to root e.g. via symlink attacks. logrotate
offers a su <user> <group> syntax to
instruct the daemon to perform a privilege drop to the user owning the
directory to avoid any security implications.
To start with, we had a look at the implementation of the logrotate daemon, to judge what the impact would be, when a rogue service user account tries to perform an attack against logrotate when it starts rotating logs in a directory controlled by the compromised user. The results are as follows:
In summary we believe that there are no overly dangerous situations that can
result from a missing su <user> <group> directive in affected logrotate
configuration files. Still we decided that it will be better to fix existing
packages and enforce that packages emitting this rpmlint diagnostic are not
allowed into openSUSE in the future. To this end we fixed a couple of
openSUSE-specific logrotate drop-in configuration files as well as an upstream
configuration file in Munge.
While looking into the credentials mismatch issue we noticed that logrotate
can end up in even more complex usage scenarios. The configuration file format
allows shell scripts to be embedded that will be executed after rotating
logfiles, for example. These scripts always run with full root privileges,
independently of an existing su <user> <group> directive. The likeliness of
security issues is higher in this case and issues are harder to detect, since
this is package-specific code possibly running as root in untrusted
directories.
While exploring all embedded scripts found in logrotate drop-in configuration files in openSUSE Tumbleweed we found out that in most cases such scripts are only used to restart a systemd service or to send a signal to a daemon running in the background. In a few cases the scripts have been problematic, as is described in the following sub-sections.
In the python-mailman package we found two problems in the embedded shell script, which consisted of these two lines:
/bin/kill -HUP $(</run/mailman/master.pid) 2>/dev/null || true
@BINDIR@/mailman reopen >/dev/null 2>&1 || true
For one, SIGHUP was sent to a PID obtained from /run/mailman/master.pid,
which is under the control of the mailman service user. This would allow a
compromised mailman user to direct SIGHUP to arbitrary processes in the
system.
Furthermore the command line /usr/bin/mailman reopen was executed with full
root privileges, which results in output like this:
Usage: mailman [OPTIONS] COMMAND [ARGS]...
Try 'mailman -h' for help.
Error: If you are sure you want to run as root, specify --run-as-root.
This shows that the intended reopen of logfiles doesn’t work as expected.
Otherwise one might think that nothing harmful happens. This is not true,
however. This invocation of mailman still leads to the full initialization
of the logging system and all the logfiles in /var/log/mailman are
created, if not already existing, with full root privileges. Symbolic links
are followed, if necessary.
This means a compromised mailman user can e.g. create a symlink
/var/log/mailman/bounce.log → /etc/evil-file. After the logrotate script
runs /etc/evil-file will be created. The files will be created with
root-ownership, so the only impact of this should be the creation of new empty
files owned by root in the system. This can still have security impact when
such empty state files control sensitive settings of other programs in the
system.
To fix this issue the sending of SIGHUP was completely dropped and the
reopen command is invoked via sudo as the dedicated mailman service user
and group. The logrotate drop-in configuration file containing the
problematic script is specific to openSUSE, thus we assigned a CVE for this
issue to make our users aware.
The sssd package has a very similar issue in its
example logrotate configuration, where a SIGHUP
signal is sent to a PID controlled by the sssd service user:
/bin/kill -HUP `cat @pidpath@/sssd.pid 2>/dev/null` 2> /dev/null || true
We created a public upstream GitHub issue to make the developers aware of the problem. There is no fix available yet for the issue.
In our icinga2 package there is yet another instance of sending a signal
(SIGUSR1) to a PID controlled by the unprivileged icinga service user:
/bin/kill -USR1 $(cat /run/icinga2/icinga2.pid 2> /dev/null) 2>/dev/null || true
We wanted to change that into a systemctl reload icinga2.service instead,
only to find out that upstream’s reload script is affected by the same
issue. We reported the problem to upstream and they
fixed it and assigned a CVE by now.
Our exim package contained a problematic prerotate shell script in its
logrotate configuration which allows escalation from
the mail user/group to root, when it runs. The
shell script is rather complex and tries to generate a statistics report
creating temporary files as root in the log directory owned by the
unprivileged mail user.
To fix this, the script has been adjusted to use a private temporary directory for the report, instead. An update containing the fix will soon be available for openSUSE Tumbleweed.
This again is an openSUSE specific logrotate configuration file, thus we assigned a CVE to mark the problem.
The issues we uncovered show also room for improvement in logrotate itself to
prevent such situations in the first place. For one, the daemon could refuse
to work on directories owned by non-root users, like it does for
world-writable directories. Furthermore scripts could be executed using the
same su <user> <group> credentials that are used for rotating the logs.
We did not reach out to upstream about these suggestions yet, but will keep you informed about any developments in this area.
GNOME 49 was recently released and our GNOME maintainers asked us to look into a number of D-Bus and Polkit changes that appeared in related packages. We encountered nothing too exciting this time:
gdm group instead of to the gdm
user. This is related to the display manager now using dynamic user
accounts.gdm group is now allowed to access smart cards managed by
pcscd. This is supposed to fix a bug report where
smart cards could not be accessed by GDM. Why this bug never occurred
before is not completely clear, the Polkit settings are acceptable in any
case.gdm group, not the
user.gdm group instead
of the user.backlight-helper. Locally logged in
regular users are allowed to execute this program with root privileges to
control the backlight of mobile devices. We have seen this helper program
before in the gnome-settings-daemon package. It is a minimal C program
consisting of 200 lines of code and we could not find any issues in it.Earlier this year we reported a number of local security issues pertaining to the REST API in Kea DHCP. In a follow-up review we focused on the network attack surface, which usually is the more interesting part when dealing with a DHCP server suite. Alas, while looking at the network logic we stumbled over another minor local security issue regarding a temporary change to the process’s umask. Upstream addressed the problem in the meantime.
Following the actual network processing logic in Kea’s code base is no easy task. The C++ coding style uses a high level of abstraction which leads to many indirections. Untrusted data received from network peers travels far in the code without clear logical boundaries where data is verified before further processing takes place. The code base contains a lot of comments, which usually is a good thing, but in this instance it felt nearly too verbose to us, making it hard to find the relevant bits.
On the positive side of things Kea is already a matured project and there were no easy pickings to be found. Upstream also integrated AFL fuzzing into their testing infrastructure, which should allow them to find network security issues proactively. Consequently we have been unable to find any security issues in the network processing in Kea.
Kea offers advanced features like configuring custom behaviour depending on specific DHCP header fields. This naturally comes with quite some additional complexity. In this light we believe Kea is well suited for large organizations, but we would recommend a simpler DHCP server implementation for small environments where such features are not needed, to reduce attack surface.
This finding resulted from our logrotate configuration
file investigation discussed above. chrony is the
default NTP time synchronization program used in openSUSE and a number of
other Linux distributions. It ships a logrotate drop-in configuration
file that contains this postrotate shell code:
postrotate
/usr/bin/chronyc cyclelogs > /dev/null 2>&1 || true
endscript
chronyc is the client utility used to talk to the chronyd daemon
component. The communication mechanism used for this is a UNIX domain socket
placed in /run/chrony/chronyd.sock. chronyc is invoked as root in the
logrotate context above. At first we believed this should not be a problem,
since any privileged process should be allowed to talk to chronyd. While
looking at the strace output of the command line above the following system
call caught our attention, however:
chmod("/run/chrony/chronyc.6588.sock", 0666) = 0
The /run/chrony directory is owned by the chrony service user:
drwxr-x--- 3 chrony chrony 100 Sep 25 09:45 .
These are the same credentials used by the chronyd daemon. When root
performs the chmod call above, then a compromised chrony service user has
an opportunity to perform a symlink attack, directing the chmod() operation
to arbitrary files on the system, making them world-writable, thus making
possible a chrony to root privilege escalation. A couple of years ago we
found a somewhat similar symlink attack in the area
of the pidfile creation performed by the daemon.
We approached upstream about the issue on July 15 by creating a private
issue in their GitLab project. The bugfix
turned out rather complex. The problem here is that the UNIX domain socket
used by chrony is datagram-oriented (SOCK_DGRAM). This means there is no
connection established between client and server. For the server being able to
send back data to the client, the client needs to bind its socket into the
file system as well and grant the server-side access to it. On Linux an
autobind feature exists for Unix domain sockets, which will automatically
assign an abstract address to the client socket, which is not visible in the
file system. This feature is not available on other UNIX systems, however,
that chrony also intends to support.
For these reasons the upstream approach to fix this involves the creation of
an unpredictably named sub-directory in /run/chrony to place the client-end
socket into. The directory is only writable for the client and the
unpredictable directory name is not known in advance, thus no symlinks can be
placed into the path anymore.
A fellow SUSE engineer recently finished development on
pwaccessd, a daemon providing user account information
via Varlink. This novel approach to providing account information allows, for
example, to grant regular users access to their own shadow entry, which would
otherwise only be accessible to root.
At the end of June we have been asked to review the new daemon for its security. We had a couple of hardening recommendations and found an instance of possible log spoofing, but have otherwise been satisfied with the implementation. Bugfixes and improvements have been incorporated and the new service is now ready to be used in production.
sysextmgr is another new Varlink service developed by SUSE, which this time helps with the management of systemd-sysext images on openSUSE MicroOS. We noticed the addition of this service to openSUSE via our monitoring of newly added systemd services in the distribution. While looking into the Varlink API we discovered a number of issues in the service like Denial-of-Service attack surface and some minor symlink issues. The issues could be resolved quickly and we are now happy with the state of the service.
Our team is currently undertaking an effort to have a look at all kinds of
shell related drop-in code like command-specific shell completion support and
files installed into /etc/profile.d to manipulate the shell environment.
Any packages can install such files and they can easily lead to security
problems when things are not done right.
The amount of such files in a complete Linux distribution is huge, naturally,
thus this is a long-term task that will require time to produce a complete
list of findings. A first finding in the
bash-git-prompt package already resulted from this, however.
This package installs shell code into /etc/profile.d/bash-git-prompt.sh
which enables an interactive Git prompt which will be displayed as soon as the
Bash shell enters a Git repository. This prompt contains information about
the current repository, the number of modified files and other things that can
be configured by users. The prompt feature using default settings becomes
active as soon as the package is installed.
While looking into the shell code that implements all this we noticed the use
of a predictable temporary file in
/tmp/git-index-private$$. bash-git-prompt copies the Git index file found
in the current Git repository to this location. It turns out that this copy
operation happens every time the interactive shell user enters a new command
while being located in a Git repository. The temporary file is soon deleted
again when the Git bash prompt has been fully rendered by the program.
Since an interactive bash shell session is a long-lived process it is rather simple for other users in the system to pre-create the temporary file in question and cause all kinds of issues:
022 is used, then the copy of the Git
index becomes world-readable in /tmp. If the victim’s Git repository
contains non-public data then part of that data (e.g. file names of pending
change sets) leaks to other users in the system.bash-git-prompt fails to write the desired Git index data to this
location, but will not stop execution despite this error. The crafted Git
index data will be fed to various invocations of the git command line
utility, possibly leading to a crafted bash prompt or even leading to some
forms of code execution. To determine the full extent of this, a low level
analysis of the handling of the binary Git index format would be necessary.The problem was discovered independently a while ago already, which is why
there exists a public GitHub issue for it. An upstream
author attempted to fix the issue, but rolled back the changes due to a
regression and nothing happened since. The issue was introduced via commit
38f7dbc0bb8 in bash-git-prompt version 2.6.1. We
added a simple patch to our packaging of bash-git-prompt
which should address all issues for users of openSUSE.
At the end of September we requested a CVE from Mitre to track this issue and they assigned CVE-2025-61659.
Our team’s monitoring of newly added systemd services in openSUSE led us to steam-powerbuttond. It derives from a script found on the SteamOS Linux distribution for use on Steam Deck gaming devices.
The main component of this package is a Python script which runs as a systemd
service with full root privileges. This script contains various security
issues. During startup the script attempts to
determine who “the first user” in the system is, by parsing the output of who
| head -1. This user’s home directory is then used for operations later on,
when a power button press event is detected. After processing the event, the
file /home/{user}/.steam/steam.pid is read and used for accessing
/proc/{pid}/cmdline.
This logic leads to various possible issues, ranging from the the wrong user being selected initially, to denial-of-service when unexpected file content is placed in the unprivileged user’s home directory. We contacted one of the original upstream authors about this and offered coordinated disclosure. It turned out that the project is not supposed to be used anymore, however, and as a result the GitHub repository has been archived by the maintainer.
The openSUSE steam-powerbuttond package is now waiting to be replaced by a
new script that is supposed to be found in SteamOS.
This edition of the SUSE security team spotlight was quite packed with topics. We hope this can give you an insight into all the different kind of activities we end up in on our mission to improve the security of open source software, in the Linux ecosystem in general and openSUSE in particular. We’re looking forward to the next issue of the spotlight series in about three months from now.
| 2025-10-23 | Updated the logrotate Icinga2 sub-section to include the upstream CVE and a link to the upstream security advisory. |