In short:
A memory corruption bug was discovered in the nscd (Name Service Cache Daemon) component of glibc—specifically in the netgroup cache logic. By exploiting CVE-2024-33602, an attacker may cause memory corruption in nscd, which could lead to crashes or even code execution, depending on circumstances. If your system uses nscd and its netgroup cache, read on.
What’s the Vulnerability?
CVE-2024-33602 describes:
The nscd netgroup cache assumes the Name Service Switch (NSS) callback always stores string data in a given buffer. If the callback doesn't, nscd may use and cache out-of-bounds memory (strings that aren't in the buffer), leading to undefined behavior and possible memory corruption.
Present since:
glibc 2.15 (when netgroup cache was first added to nscd)
Platform:
Only systems using the nscd binary for name caching (common in certain Linux/Unix environments).
Not affected:
Technical Explanation in Simple Language
nscd speeds up address/name lookups on Linux by caching results from /etc/passwd, /etc/group, and various network-related files, using NSS plugins for data sources.
For netgroup queries, nscd keeps a cache for quick lookups. When it asks a backend for netgroup data, it allocates a buffer, expecting all returned strings to be inside this buffer. But if a backend returns a pointer to a string located elsewhere in memory, nscd still thinks it can use or cache that pointer as if it pointed inside the buffer. The result? Memory corruption—a classic coding error.
Exploit Details
An attacker can exploit this bug if they have *some* way to trigger netgroup lookups involving malicious or poorly behaving NSS modules, or if the system's configuration encourages nonstandard data sources (especially custom NSS modules).
What can go wrong?
- Overwrites/corruption of memory used by nscd
Potential for code execution (depending on the system’s protections and how memory is corrupted)
Example Attack Vectors:
Malicious NSS module returns a non-buffer pointer
- Invalid or crafted /etc/netgroup entries (if NSS module passes them through)
Below is a *simplified* code snippet to show the problem (for demonstration only)
// Buffer supplied to NSS module
char buffer[BUF_SIZE];
// NSS backend fills in strings and returns pointers
char *name = nss_get_netgroup_name(..., buffer, BUF_SIZE);
// nscd assumes 'name' points inside 'buffer'
if (name >= buffer && name < buffer + BUF_SIZE) {
// Safe: pointer is inside the buffer
cache_save(name);
} else {
// But bug: this check may be missing!
cache_save(name); // *dangerous if outside buffer*
}
In reality, nscd caches the returned string, believing it's always within the allocated buffer.
Does your system use netgroups?
Look for references to netgroup in /etc/nsswitch.conf
Latest versions have patched this bug. Follow your distribution's advisory.
- Red Hat Security Advisory
- Debian glibc patch
- Upstream glibc commit fixing netgroup cache
sudo systemctl disable nscd
Or, disable netgroup caching in /etc/nscd.conf:
enable-cache netgroup no
`
---
## References
- CVE-2024-33602 at MITRE
- Upstream glibc bug report
- Red Hat Security Blog
- Debian Security Tracker
- Original patch commit
---
## Summary
CVE-2024-33602 is a classic "trust the buffer" bug in a critical system service, lurking for over a decade. It highlights the importance of defense in depth and careful backend interaction in system programming. Scan your systems, patch if affected, and remember: what nscd caches, everyone shares—so keep it safe!
---
*This article is exclusive and aims to provide actionable, easy-to-understand insights for system administrators and users worried about CVE-2024-33602.*
Timeline
Published on: 05/06/2024 20:15:11 UTC
Last modified on: 07/22/2024 18:15:03 UTC