A recently discovered vulnerability, CVE-2023-4641, has quietly drawn attention among security researchers and system administrators. At its core, the bug is simple but serious—when you set a new password on many Linux systems, there’s a chance your password might linger in memory, just waiting for someone with the right access to find it. This vulnerability lies in a widely-used suite called shadow-utils, which handles password-related tasks like changing user passwords.

In this article, we’ll dig into what shadow-utils does, how this particular bug works, look at some code, see what an attacker could do, and learn how to protect your system.

What is shadow-utils?

shadow-utils is a package found on virtually every Linux system. It provides programs for handling user passwords, user accounts, and group data. One of its core tasks is making sure passwords are not saved as plain-text in files that anyone can see; instead, it uses hashed versions in /etc/shadow. But passwords also get processed in memory—and that’s where our story starts.

The Vulnerability: Stale Passwords Left in Memory

Let’s say you’re using the passwd command to change your password. Normally, you’ll be asked to enter your new password twice to confirm you didn't make a typo:

$ passwd
Enter new UNIX password: [first input]
Retype new UNIX password: [second input]

If the passwords match, everything’s fine—they’re saved (in hashed form) and the buffers holding your input are wiped clean. But if the second entry fails (you make a typo the second time), it turns out the first password stays in memory.

From the Red Hat official advisory

> When asking for a new password, shadow-utils asks the password twice. If the password fails on the second attempt, shadow-utils fails in cleaning the buffer used to store the first entry. This may allow an attacker with enough access to retrieve the password from the memory.

That means anyone who has the right access can potentially grab your password straight from RAM after you typed it!

Let’s check a simplified version of what happens in the code (in C-like pseudocode)

char first_password[MAX_LEN];
// get first password from user
read_password(first_password, "Enter new UNIX password:");

// get second password
char second_password[MAX_LEN];
read_password(second_password, "Retype new UNIX password:");

// check if password matches
if (strcmp(first_password, second_password) != ) {
    printf("Sorry, passwords do not match.\n");
    // here's the bug: first_password is NOT wiped from memory!
    return 1;
}

// Wipe passwords for security
memset(first_password, , MAX_LEN);
memset(second_password, , MAX_LEN);

In the failing path, the program returns early before it wipes first_password from memory. This means that string data (your password) stays in the process memory and could show up in memory dumps.

Real-World Exploit Scenario

Imagine an attacker with root or debugging privileges, or perhaps malware running at high privilege. This attack is not remotely exploitable by unprivileged users, but with the right access, here’s what could go wrong:

1. Attacker monitors the passwd process using tools like gcore to dump process memory or attaches with gdb right after a failed password change.
2. Attacker searches for password data by looking for ASCII sequences matching password policy formats.
3. If the victim typed their real password as the *first attempt* and messed up the *second one*, the attacker has a shot at discovering it.

Let’s show how an attacker might extract the password from a memory dump

# 1. User fails to confirm their new password
$ passwd
Enter new UNIX password: S3cur3P@ssword123
Retype new UNIX password: S3cur3P@ssworD123
Sorry, passwords do not match.

# 2. Attacker dumps the process memory (as root)
$ pidof passwd
5678
$ gcore 5678
$ strings core.5678 | grep 'S3cur3'
S3cur3P@ssword123

If the timing is right, the password is sitting unprotected in the dump!

What Should You Do?

Update Immediately. Vendors like Red Hat, Debian, and SUSE have patched the issue. Update your system packages for shadow-utils.

References and Further Reading

- Red Hat CVE-2023-4641 Security Advisory
- NVD Entry for CVE-2023-4641
- shadow-utils Github
- Debian Security Tracker

Conclusion

CVE-2023-4641 is a classic example of how little details—forgetting to clear a buffer—can create unexpected leaks in an otherwise trusted tool. Always keep your systems up to date, and remember: every input, especially passwords, should be wiped thoroughly from memory after use.

If you’re a sysadmin, patch your servers. If you’re a user, update regularly and be skeptical about system security, even for simple commands like passwd.

Timeline

Published on: 12/27/2023 16:15:13 UTC
Last modified on: 01/04/2024 17:06:55 UTC