CVE-2021-33910: Denial of Service (Stack Exhaustion) in systemd (PID 1)

The Qualys Research Team has discovered a stack exhaustion denial-of-service vulnerability in systemd, a near-ubiquitous utility available on major Linux operating systems. Any unprivileged user can exploit this vulnerability to crash systemd and hence the entire operating system (a kernel panic).

About systemd

systemd is a software suite that’s included in most Linux-based OSes. It provides an array of system components for Linux operating systems. It provides a system and service manager that runs as PID 1 and starts the rest of the system.

Impact

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

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

Disclosure Timeline

• 2021-06-09: We sent our advisories for CVE-2021-33909 and CVE-2021-33910 to Red Hat Product Security (the two vulnerabilities are closely related and the systemd-security mailing list is hosted by Red Hat).
•  2021-07-06: We sent our advisories, and Red Hat sent the patches they wrote, to the linux-distros@openwall mailing list.
•  2021-07-20: Coordinated Release Date (12:00 PM UTC)

Technical Details

systemd monitors and parses the contents of /proc/self/mountinfo, and passes each mountpoint path to mount_setup_unit(), which passes it to unit_name_from_path(), which passes it to unit_name_path_escape():

------------------------------------------------------------------
 1720 static int mount_load_proc_self_mountinfo(Manager *m, bool set_flags) {
 ….
 1727         r = libmount_parse(NULL, NULL, &table, &iter);
 ….
 1731         for (;;) {
 ….
 1735                 r = mnt_table_next_fs(table, iter, &fs);
 ….
 1742                 path = mnt_fs_get_target(fs);
 ….
 1751                 (void) mount_setup_unit(m, device, path, options, fstype, set_flags);
------------------------------------------------------------------
 1644 static int mount_setup_unit(
 1645                 Manager *m,
 1646                 const char *what,
 1647                 const char *where,
 1648                 const char *options,
 1649                 const char *fstype,
 1650                 bool set_flags) {
 ….
 1683         r = unit_name_from_path(where, ".mount", &e);
------------------------------------------------------------------
 512 int unit_name_from_path(const char *path, const char *suffix, char **ret) {
 …
 523         r = unit_name_path_escape(path, &p);
------------------------------------------------------------------
 380 int unit_name_path_escape(const char *f, char **ret) {
 …
 386         p = strdupa(f);
------------------------------------------------------------------

At line 386, unit_name_path_escape() passes the mountpoint path to strdupa(), which is similar to strdup() but allocates memory on the stack (via alloca()), not in the heap (via malloc()).

As a result, if the total path length of this mountpoint exceeds 8MB (the default RLIMIT_STACK), then systemd crashes with a segmentation fault that also crashes the entire operating system (a kernel panic, because systemd is the “global init”, PID 1).

Solution

Given the breadth of the attack surface for this vulnerability, Qualys recommends users apply patches for this vulnerability immediately.

Qualys customers can search the vulnerability knowledgebase for CVE-2021-33910 to identify all the QIDs and assets vulnerable for this vulnerability.

If you are not a customer, start your free Qualys VMDR trial to get full access to the QIDs (detections) for CVE-2021-33910, so you can identify your vulnerable assets.

Qualys Coverage

Qualys is releasing the QIDs in the table below as they become available starting with vulnsigs version VULNSIGS-2.5.237-3 and in Linux Cloud Agent manifest version lx_manifest-2.5.237.3-2

Discover Vulnerable Linux Servers Using Qualys VMDR

Identify Assets Running systemd

The first step in managing these critical vulnerabilities and reducing risk is identification of assets running systemd software. Qualys VMDR makes it easy to identify such assets.

Query: software:(name:"systemd")

Once the hosts are identified, they can be grouped together with a ‘dynamic tag’, let’s say – “Linux systemd Servers”. This helps in automatically grouping existing hosts with the above vulnerabilities as well as any new Linux assets that spin up in your environment. Tagging makes these grouped assets available for querying, reporting and management throughout the Qualys Cloud Platform.

Prioritize Based on RTIs

Using VMDR, the Exim vulnerabilities can be prioritized using the following real-time threat indicators (RTIs):

Predicted_High_Risk
Denial_of_Service
Easy_Exploit

Detect Impacted Assets with Threat Protection

VMDR also enables you to automatically map assets vulnerable to these vulnerabilities using Threat Protect.

Dashboard

With VMDR Unified Dashboard, you can track this vulnerability, their impacted hosts, their status and overall management in real time. With trending enabled for dashboard widgets, you can keep track of these vulnerabilities trends in your environment.

View and download the “Sequoia” dashboard:

Vendor References

https://www.qualys.com/2021/07/20/cve-2021-33910/denial-of-service-systemd.txt

Frequently Asked Questions (FAQs)

What versions are vulnerable?

All systemd versions from April 2015 onwards are vulnerable.

Will the Qualys Research Team publish exploit code for this vulnerability?

A PoC is attached with the advisory and available at https://www.qualys.com/research/security-advisories/.

Are there any mitigations for this vulnerability?

No.