systemd v233 and earlier fails to safely parse usernames starting with a numeric digit (e.g. "0day"), running the service in question with root privileges rather than the user intended.

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 stack-based buffer overflow vulnerability was found in getpwnam()/getgrnam() functions of NSS module nss-mymachines provided by systemd.

systemd 242 changes the VT1 mode upon a logout, which allows attackers to read cleartext passwords in certain circumstances, such as watching a shutdown, or using Ctrl-Alt-F1 and Ctrl-Alt-F2. This occurs because the KDGKBMODE (aka current keyboard mode) check is mishandled.

DISPUTED systemd 239 through 245 accepts any certificate signed by a trusted certificate authority for DNS Over TLS. Server Name Indication (SNI) is not sent, and there is no hostname validation with the GnuTLS backend. NOTE: This has been disputed by the developer as not a vulnerability since hostname validation does not have anything to do with this issue (i.e. there is no hostname to be sent).

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 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

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.

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 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.

systemd-tmpfiles in systemd before 237 attempts to support ownership/permission changes on hardlinked files even if the fs.protectedhardlinks sysctl is turned off, which allows local users to bypass intended access restrictions via vectors involving a hard link to a file for which the user lacks write access, as demonstrated by changing the ownership of the /etc/passwd file.

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.

An integer overflow, leading to heap-based buffer overflow flaw was found in the way journald functionality of systemd, a system and service manager, processed native messages. A local attacker could provide a specially-crafted packet that when processed by systemd would lead to systemd daemon crash or, potentially, arbitrary code execution with the privileges of the user running the daemon.

Issue found by Florian Weimer, Red Hat Product Security Team

Upstream patch: [1] http://cgit.freedesktop.org/systemd/systemd/commit/?id=505b6a61c22d5565e9308045c7b9bf79f7d0517e

In systemd 223 through 235, a remote DNS server can respond with a custom crafted DNS NSEC resource record to trigger an infinite loop in the dnspacketreadtypewindow() function of the 'systemd-resolved' service and cause a DoS of the affected service.

In systemd through 233, certain sizes passed to dnspacketnew in systemd-resolved can cause it to allocate a buffer that's too small. A malicious DNS server can exploit this via a response with a specially crafted TCP payload to trick systemd-resolved into allocating a buffer that's too small, and subsequently write arbitrary data beyond the end of it.

systemd-resolved through 233 allows remote attackers to cause a denial of service (daemon crash) via a crafted DNS response with an empty question section.

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 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".

Sebastian Krahmer reported a security issue was found in polkit (CVE-2013-4288 bz 1002375).

It was found that systemd was vulnerable to this issue as well, since it communicated to polkit authority using an unsafe DBUS interface.

This issue has been assigned CVE-2013-4327

A flaw was found in the way systemd handled empty notification messages. A local attacker could use this flaw to make systemd freeze its execution, preventing further management of system services, system shutdown, or zombie process collection via systemd.

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.

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

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

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 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.