A new vulnerability was discovered in Systemd

A vulnerability was found in systemd which is already described in (CVE-2019-6454), what allows to cause the control initialization process (PID1) to block when sending a specially crafted message to a non-privileged user over the D-Bus.

The Red Hat developers also do not exclude the possibility of using the vulnerability to organize code execution with root privileges., but the final possibility of such an attack has not yet been determined.

About systemd

For those who do not know Systemd I can tell you that this is a linux initialization system and service manager which includes features such as on-demand daemon startup, automount and mount point maintenance, snapshot support, and process tracking using Linux control groups.

Systemd provides a registry daemon and other tools and utilities to help with common system administration tasks. Lennart Poettering and Kay Sievers wrote SystemD, inspired by macOS launchd and Upstart, with the goal of creating a modern and dynamic system.

In particular, systemd provides aggressive parallelization capabilities and dependency-based service control logic, allowing services to start in parallel and leading to faster startup times. These two aspects were present in Upstart, but enhanced by systemd.

Systemd is the default boot system for major Linux distributions, but it is backward compatible with SysV startup scripts.

SysVinit is an initialization system that precedes systemd and uses a simplified approach to start the service. Systemd not only manages system initialization, but also provides alternatives to other well-known utilities such as cron and syslog.

About the new systemd vulnerability

By manipulating the size of the message sent through the D-Bus, an attacker can move the pointer beyond the limits of memory allocated for the stack, bypassing the protection of "stack guard-page", which is based on the substitution of a memory page at the edge that calls an exception (page fault).

The successful attack is demonstrated on Ubuntu 18.10 with systemd 239 and on CentOS 7.6 with systemd 219.

As a workaround, compilation can be used in GCC with the "-fstack-clash-protection" option, which is used by default in Fedora 28 and 29.

It should be noted that in 2014 the author of the MUSL system library pointed out among the main architectural problems systemd excessive inflation PID1 handler and questioned the feasibility of implementing a PID1 level controller API for Link with the Bus, since it is a serious vector for attacks and can adversely affect the reliability of the entire system

According to a security researcher who revealed a vulnerability, a stack pointer change is possible only for unused memory pages (unassigned), which does not allow to organize code execution in the context of the PID1 process, but allows an attacker to initiate the PID1 lock with a subsequent transition of the Linux kernel to the "panic" state (in the case of PID controller 1 failure, the entire system hangs).

In systemd, a signal handler is installed that tries to trap the faults of the PID1 process (segmentation fault) and starts the shell for recovery.

But since, during the attack, a call is made to non-duplicated (unallocated) memory pages, the kernel cannot call this signal handler and just terminates the process with PID 1, which in turn does It is impossible to continue working and go to the "panic" state, so a system restart is required.

There is already a solution to the problem

Like any security problem already described and reported, its publication cannot be made until the problem has been solved and vulnerability patch updates for SUSE / openSUSE, Fedora have already been released, also for Ubuntu and partly for Debian (Debian Stretch only).
Although the problem remains uncorrected in RHEL.