Found a denial of service vulnerability affecting systemd

A few days ago the news was released that the investigation team of Qualys discovered a denial of service vulnerability due to stack exhaustion in systemd, so any non-privileged user can exploit this vulnerability to block systemd.

Vulnerability already cataloged as (CVE-2021-33910) It is mentioned that it affects systemd is caused by a failure when trying to mount a directory with a path size greater than 8 MB through FUSE and in which the control initialization process (PID1) runs out of stack memory and is locks up, putting the system in a "panic" state.

This vulnerability was introduced in systemd v220 (Apr 2015) by commit 7410616c ("kernel: rework unit name manipulation and validation logic"), which replaced a strdup () on the heap with a strdupa () in the battery. Successful exploitation of this vulnerability allows any unprivileged user to cause denial of service through kernel panic.

As soon as the Qualys research team confirmed the vulnerability, Qualys participated in responsible disclosure of the vulnerability and coordinated with the author and open source distributions to announce the vulnerability.

The researchers mention that the problem related to CVE-2021-33910 arises due to the fact that systemd monitors and parses the content of / proc / self / mountinfo and it handles each mount point in the unit_name_path_escape () function which causes an operation called "strdupa ()" to be executed which takes care of allocating the data on the stack instead of the heap.

That is why since maximum allowed stack size is limited by the "RLIMIT_STACK" function, handling too long a path to the mount point causes the "PID1" process to hang which leads to the system stopping.

In addition, they mention that for an attack to be functional, the simplest FUSE module can be used in combination with the use of a highly nested directory as a mount point, whose path size exceeds 8 MB.

Also It is important to mention that the Qualys researchers make mention of a particular case with vulnerability, since especially with systemd version 248, the exploit is not functional due to a bug that is present in the systemd code that causes / proc / self / mountinfo to fail. It is also interesting that a very similar situation arose in 2018, as while trying to write an exploit for the CVE-2018-14634 vulnerability in the Linux kernel, in which Qualys researchers found three other critical vulnerabilities in systemd.

About vulnerability Red Hat team mentioned any product that is RHEL compliant will also potentially be affected.

This includes:

  • Product containers that are based on RHEL or UBI container images. These images are updated regularly, and the container status indicating whether a fix is ​​available for this flaw can be viewed in the Container Health Index, part of the Red Hat Container Catalog (https://access.redhat.com/containers).
  • Products that pull packages from the RHEL channel. Make sure the underlying Red Hat Enterprise Linux systemd package is up to date in these product environments.

Due to the breadth of the attack surface of this vulnerability, Qualys recommends users to apply the appropriate patches (which were already released a few days ago) for this vulnerability immediately.

As already mentioned the problem has appeared since systemd 220 (Apr 2015) and has already been fixed in the main repository of systemd and has been fixed on most distributions Linux main, as well as its derivatives, you can check the status in the following links (Debian, Ubuntu, Fedora, RHEL, SUSE, Arch).

Finally, if you are interested in knowing more about it about this vulnerability, you can check the details of it In the following link.


Be the first to comment

Leave a Comment

Your email address will not be published. Required fields are marked with *

*

*

  1. Responsible for the data: Miguel Ángel Gatón
  2. Purpose of the data: Control SPAM, comment management.
  3. Legitimation: Your consent
  4. Communication of the data: The data will not be communicated to third parties except by legal obligation.
  5. Data storage: Database hosted by Occentus Networks (EU)
  6. Rights: At any time you can limit, recover and delete your information.