A race condidition in systemd-coredump allows a local attacker to crash a SUID program and gain read access to the resulting core dump

systemd before 247 does not adequately block local privilege escalation for some Sudo configurations, e.g., plausible sudoers files in which the "systemctl status" command may be executed. Specifically, systemd does not set LESSSECURE to 1, and thus other programs may be launched from the less program. This presents a substantial security risk when running systemctl from Sudo, because less executes as root when the terminal size is too small to show the complete systemctl output.

systemd 250 and 251 allows local users to achieve a systemd-coredump deadlock by triggering a crash that has a long backtrace. This occurs in parseelfobject in shared/elf-util.c. The exploitation methodology is to crash a binary calling the same function recursively, and put it in a deeply nested directory to make its backtrace large enough to cause the deadlock. This must be done 16 times when MaxConnections=16 is set for the systemd/units/systemd-coredump.socket file.

An off-by-one Error issue was discovered in Systemd in formattimespan() function of time-util.c. An attacker could supply specific values for time and accuracy that leads to buffer overrun in formattimespan(), leading to a Denial of Service.

A heap use-after-free vulnerability was found in systemd before version v245-rc1, where asynchronous Polkit queries are performed while handling dbus messages. A local unprivileged attacker can abuse this flaw to crash systemd services or potentially execute code and elevate their privileges, by sending specially crafted dbus messages.

Last updated 24 July 2024

In nspawn in systemd 233 through 259 before 260, an escape-to-host action can occur via a crafted optional config file.

In udev in systemd before 260, local root execution can occur via malicious hardware devices and unsanitized kernel output.

A flaw in systemd v228 in /src/basic/fs-util.c caused world writable suid files to be created when using the systemd timers features, allowing local attackers to escalate their privileges to root. This is fixed in v229.

Sebastian Krahmer of the SUSE Security Team reported that systemd-logind, a part of the systemd service and system manager, did not create certain special files in a secure way. systemd-logind is responsible for managing and tracking user login sessions, and if a user were to log into the X11 desktop, it creates entries in /run/user/[username]/X11, where /run/user/[username] is a user-owned directory. Because systemd-logind does not create the entries in a secure fashion, a malicious user could replace /run/user/[username]/X11 with a symlink to another root-owned directory, such as /etc/pam.d or /etc/cron.d. This would cause a symlink named "display" to be created in the target directory, which is a symlink to a user-owned file (/tmp/.X11-unix/X0). Using further attack vectors and this symlink, the malicious user could obtain a root shell, if he could beat two separate race conditions.

Acknowledgements:

Red Hat would like to thank Sebastian Krahmer of the SUSE Security Team for reporting this issue.

In systemd 259, systemd-journald can send ANSI escape sequences to the terminals of arbitrary users when a "logger -p emerg" command is executed, if ForwardToWall=yes is set.

In systemd 258 before 260, a local unprivileged user can trigger an assert when a Delegate=yes and User=<unset> unit exists and is running.

In systemd 259 before 260, there is local privilege escalation in systemd-machined because varlink can be used to reach the root namespace.

In systemd 260 before 261, a local unprivileged user can trigger an assert via an IPC API call with an array or map that has a null element.

A vulnerability was found in systemd. This security flaw can cause a local information leak due to systemd-coredump not respecting the fs.suiddumpable kernel setting.

A flaw was found in systemd. An uncontrolled recursion in systemd-tmpfiles may lead to a denial of service at boot time when too many nested directories are created in /tmp.

A vulnerability was found in systemd-resolved. This issue may allow systemd-resolved to accept records of DNSSEC-signed domains even when they have no signature, allowing man-in-the-middles (or the upstream DNS resolver) to manipulate records.

A use-after-free vulnerability was found in systemd. This issue occurs due to the onstreamio() function and dnsstreamcomplete() function in 'resolved-dns-stream.c' not incrementing the reference counting for the DnsStream object. Therefore, other functions and callbacks called can dereference the DNSStream object, causing the use-after-free when the reference is still used later.

A flaw was found in systemd. Attacker controlled alloca() in function unitnamepathescape() leads to a crash in systemd and ultimately a kernel panic. Systemd parses the content of /proc/self/mountinfo and each mountpoint is passed to mountsetupunit(), which calls unitnamepathescape() underneath to duplicate the string through alloca(). A local attacker who is able to mount a filesystem on a very long path can crash systemd and the whole system.

Upstream PR: https://github.com/systemd/systemd/pull/20256

Upstream commit: https://github.com/systemd/systemd/pull/20256/commits/441e0115646d54f080e5c3bb0ba477c892861ab9

systemd could allow a local authenticated attacker to gain elevated privileges on the system, caused by the mishandling of numerical usernames. By sending a specially-crafted request, an attacker could exploit this vulnerability to gain elevated privileges as root.

An issue was discovered in buttonopen in login/logind-button.c in systemd before 243. When executing the udevadm trigger command, a memory leak may occur.

A buffer overflow vulnerability in the dhcp6 client of systemd allows a malicious dhcp6 server to overwrite heap memory in systemd-networkd. Affected releases are systemd: versions up to and including 239.

A vulnerability in unitdeserialize of systemd allows an attacker to supply arbitrary state across systemd re-execution via NotifyAccess. This can be used to improperly influence systemd execution and possibly lead to root privilege escalation. Affected releases are systemd versions up to and including 239.

A race condition in chownone() of systemd allows an attacker to cause systemd to set arbitrary permissions on arbitrary files. Affected releases are systemd versions up to and including 239.

A TOCTOU (time-of-check time-of-use) race condition was found in the way systemd, a system and service manager, used to update file permissions and SELinux security contexts. A local attacker could use this flaw to conduct symbolic link attacks possibly leading to their ability to modify permissions / security context of a path different than originally intended / requested.

Issue found by Florian Weimer, Red Hat Product Security Team

A flaw was found in systemd-journald. A stack buffer overflow when passing several MB of arguments to a program calling syslog function. This can lead to a denial of service attack or arbitrary code execution in some cases.

A flaw was found in systemd-journald. An uncontrolled alloca() by writing a crafted message to /run/systemd/journal/socket that results in a stack buffer overflow. This can lead to a denial of service attack or arbitrary code execution in some cases.

It was discovered that a systemd service that uses DynamicUser property can create a SUID/SGID binary that would be allowed to run as the transient service UID/GID even after the service is terminated. A local attacker may use this flaw to access resources that will be owned by a potentially different service in the future, when the UID/GID will be recycled.

It was discovered that a systemd service that uses DynamicUser property can get new privileges through the execution of SUID binaries, which would allow to create binaries owned by the service transient group with the setgid bit set. A local attacker may use this flaw to access resources that will be owned by a potentially different service in the future, when the GID will be recycled.

In systemd before v242-rc4, it was discovered that pamsystemd does not properly sanitize the environment before using the XDGSEAT variable. It is possible for an attacker, in some particular configurations, to set a XDGSEAT environment variable which allows for commands to be checked against polkit policies using the "allowactive" element rather than "allowany".