Quick Summary:
A vulnerability identified as CVE-2024-33601 in glibc's Name Service Cache Daemon (nscd) can crash the nscd service because of how it handles memory allocation failures in its netgroup cache. This Denial of Service (DoS) threat can disrupt systems relying on nscd for authentication and network service lookups.

What is nscd?

nscd stands for *Name Service Cache Daemon*. It's a service used in Unix and Linux systems to cache user and group info, speeding up things like login or application startup by cutting down on repeated queries to directories like /etc/passwd or remote servers.

The Problem Explained

Starting from glibc version 2.15, nscd's netgroup cache uses functions like xmalloc and xrealloc to allocate system memory. These helpers are supposed to make allocation safer, but if the system is low on memory and one of these calls fails, they simply terminate the entire nscd process (using abort() or similar). They don't handle the error gracefully.

Why does this matter?
When nscd just dies, every client that's using it (think: login shells, sudo commands, network services, applications) gets an error, and authentication or service lookup might fail.

OSes: Any Linux distribution using glibc with nscd (from version 2.15 onward).

- What binary?: Only the nscd binary is affected. The rest of glibc or applications using netgroup info are not directly impacted.
- How triggered?: If your system runs low on memory and a netgroup lookup comes in, you may trigger this crash.

Attack Scenario

Imagine a multi-user server that uses netgroups heavily (for example, in NFS or sudoers rules). If a user or attacker finds a way to induce a lot of netgroup lookups (by, say, repeatedly connecting new clients or services with unknown user/group lookups), and at the same time the system's memory dips low (intentionally or due to high load), nscd can crash.

Proof-of-Concept

While this isn't a remote code execution, you can reliably crash nscd from the user side if you arrange these conditions:

`

4. Watch nscd logs or systemctl status nscd. If memory allocations fail during netgroup query processing, nscd will terminate.

Here’s what happens inside nscd’s code (simplified pseudocode)

void *xmalloc(size_t sz) {
    void *p = malloc(sz);
    if (!p) {
        abort();  // Or exit(1), or call a fatal error
    }
    return p;
}

char *netgroup_cache_add(...) {
    ...
    buf = xmalloc(BUFSZ);  // If system runs out of memory, xmalloc aborts
    ...
}

When the system is out of memory during a netgroup cache addition, it calls xmalloc, which aborts, killing nscd.

Real-World Impact

- Denial of Service: nscd crashes, making user/group lookups fail and possibly preventing users from logging in, authenticating to network services, etc.
- Availability Threat: Any system relying on nscd for authentication or hostname lookup is at risk.

How to Fix or Mitigate

- Upgrade glibc / nscd: Check your distro for glibc/nscd updates. Newer versions may patch memory allocation code to handle failures gracefully.

`sh

sudo bash -c 'echo "enable-netgroup-cache no" >> /etc/nscd.conf'

`

- Monitor your system: Use tools like systemd's automatic restart or monit to recover nscd if it crashes.

References & Further Reading

- CVE-2024-33601 at MITRE
- Red Hat Bugzilla: CVE-2024-33601
- Glibc Commit Introducing Netgroup Cache (2012)
- nscd(8) Linux manual page

Exclusive Take!

CVE-2024-33601 is a textbook case of why every allocation should be checked—and why daemons must not crash outright if resources run out. While the bug isn’t exploitable for code execution, it’s a possible weapon for denial-of-service attacks on shared Linux servers. Until distributions fix nscd, it's safer to turn off netgroup caching or keep an eye on service restarts.

Timeline

Published on: 05/06/2024 20:15:11 UTC
Last modified on: 08/02/2024 02:36:04 UTC