Systemd can’t seem to catch a break: New vulnerability found

Posted on by Admin
Systemd can’t seem to catch a break: New vulnerability found

Related Post


A dangerous vulnerability was found in the Linux systemd stack. Find out what it is and how to upgrade your Linux distributions.

Image: Sergey Nivens/Shutterstock

As if systemd didn’t already have enough detractors, it now has a serious vulnerability to pile onto the mix.

OK, that might be a bit hyperbolic of me. Or not. You see, systemd has (since inception) been lambasted and attacked. Why? That depends on who you ask. But from my perspective (after having covered Linux for decades), the majority of the haters hate it because it’s change. And you know how people feel about change.

SEE: Security incident response policy (TechRepublic Premium)

Truth be told, systemd has been a very good initialization system for Linux. It’s fast, reliable, secure… 

Or so it was. 

Recently researchers at Qualsys discovered a nasty little vulnerability tucked away in systemd. This flow is a Denial of Service which can be exploited by any privileged user to crash systemd and take down the entire operating system via kernel panic.

The vulnerability (CVE-2021-33910) was introduced in April 2015 with version 220 (commit 7410616c).

How the vulnerability works

According to Bharat Jogi, senior manager, Vulnerabilities and Signatures at Qualys, the vulnerability works like this:

  • unit_name_path_escape() passes the mountpoint path to strdupa() and allocates memory on the stack (via alloca()), not in the heap (via malloc()).
  • If the total path length of the mountpoint exceeds 8MB (the default RLIMIT_STACK), systemd crashes with a segmentation fault that also crashes the entire operating system.

In reality, what would have to happen would be a local malicious user mounting a file system to a very long path, which would cause too much memory to be used within systemd. For example, if you mounted /dev/sbd1 to /very/long/path/to/mount/a/drive/to/which/could/cause/a/kernel/panic/on/the/system. Although not probable, it’s not out of the realm of the possible that a Linux user might mount a filesystem to such a long path.

SEE: Linux 101: What are the Linux systemd equivalents of runlevels? (TechRepublic) 

No matter how likely this is to occur on your system(s), you are strongly urged to upgrade systemd immediately on all Linux systems that make use of this initialization stack.

How to upgrade

If you’re a Linux admin, you already know how this is done. But just in case:

On a Red Hat-based system: 

sudo dnf upgrade -y

On a Ubuntu-based system: 

sudo apt-get upgrade -y

On a SUSE-based system: 

sudo zypper update

On an Arch-based system: 

sudo pacman -Syu

Once you’ve upgraded your system, make sure to reboot so the changes take effect. 

Let me state this clearly: Do. Not. Hesitate. To. Upgrade. Your. Linux. Machines. Do it now, not later. Although the likelihood of this attack affecting you is small, it’s still a dangerous vulnerability. And since it’s one you can absolutely avoid with a quick upgrade, you would be seriously remiss if you didn’t take the time to update every Linux machine you manage.

You’ve been warned.

Also see



Source link