Proteggere cPanel dalle race condition dei symlink

Proteggere cPanel dalle race condition dei symlink

Le race condition sui symlink non sono un dettaglio teorico: in ambienti hosting multiutente possono trasformarsi in letture o scritture fuori dal perimetro previsto, con effetti che vanno dalla compromissione di dati tra account fino all’escalation di privilegi locali. In un contesto cPanel/WHM il tema è ancora più delicato perché convivono processi di sistema, servizi web, script utente e configurazioni automatizzate che toccano filesystem condivisi, home degli utenti, log, cache e directory temporanee.

Il punto non è “eliminare i symlink” in assoluto. Il punto è impedire che un processo privilegiato segua un link creato o sostituito in modo opportunistico da un utente non fidato, soprattutto quando l’operazione avviene in una finestra temporale fra controllo e uso del path. Questa è la classica race condition: il sistema verifica un file, poi lo usa, ma nel mezzo il target cambia.

Perché cPanel è un bersaglio sensibile

In cPanel convivono più superfici di rischio:

• account shared hosting con filesystem separati ma servizi comuni;
• processi che girano come root o con privilegi elevati;
• script di manutenzione, backup, restore e deploy che operano su path dinamici;
• web server e PHP handler che possono accedere a directory utente;
• tooling di pannello che crea, sposta o valida file in modo automatico.

Se un processo privilegiato accede a un path controllabile da un utente, il rischio nasce quando il path può essere rimpiazzato con un symlink verso una destinazione inattesa, magari dopo un controllo preliminare. Il classico errore è affidarsi a check come “esiste”, “è un file regolare”, “appartiene all’utente giusto”, senza mantenere quella garanzia fino al momento dell’uso effettivo.

Nel mondo hosting, i punti critici ricorrenti sono directory temporanee, log rotati, upload, cache applicative, file di lock, script di backup, import/export, e operazioni che attraversano home directory e percorsi condivisi come /tmp, /var/tmp, /home/*/public_html e sottodirectory di applicazioni web.

Modello di minaccia pratico

Il caso tipico è questo: un servizio con privilegi elevati deve aprire o modificare un file in un path che un utente può influenzare. Il servizio controlla il path, ma non lo apre in modo atomico o non impedisce la risoluzione dei symlink. L’utente sostituisce il file o la directory con un symlink verso un target sensibile. Se la finestra è sufficiente, il servizio scrive dove non dovrebbe.

Le varianti più comuni sono tre:

1. lettura di file sensibili tramite symlink in percorsi serviti dal web server o da job di manutenzione;
2. scrittura/overwrite di file di configurazione o script tramite path controllato dall’utente;
3. esecuzione indiretta di contenuto manipolato attraverso upload, cache o directory temporanee.

La mitigazione efficace non si basa su un solo interruttore. Serve una catena di controlli: filesystem mount, permessi, configurazione dei servizi, hardening dei path, policy di apertura file e audit continuo.

Strategia di difesa a più livelli

La regola pratica è semplice: non fidarti mai del path solo perché “sembra” corretto. Devi ridurre al minimo i punti in cui un processo privilegiato segue symlink in zone scrivibili dagli utenti.

1. Riduci i privilegi dei processi che toccano path utente. Quando possibile, fai eseguire operazioni sul filesystem con l’utente proprietario o con un servizio dedicato a privilegi minimi. In cPanel questo vale per script custom, task schedulati, hook e tool di automazione. Più un processo è root, più il problema diventa grave.

2. Separa bene i percorsi scrivibili dagli utenti da quelli sensibili. Directory come cache, upload e temp devono stare in aree ben definite, con permessi coerenti e mount option adeguate. Evita che un path usato da root sia anche scrivibile da un account condiviso, direttamente o indirettamente.

3. Usa controlli atomici e API sicure quando apri file. In codice, l’apertura deve avvenire in modo da non seguire symlink quando non è previsto. A livello di sistema e applicazione, il controllo del path deve essere legato all’operazione finale, non a una verifica separata e distante nel tempo.

4. Impedisci la sostituzione opportunistica di file e directory. Proteggi directory temporanee e di lavoro con permessi stretti, sticky bit dove appropriato, e cleanup periodico. Se un utente può creare un oggetto in una directory condivisa, deve essere molto più difficile trasformarlo in un vettore di abuso.

5. Monitora gli accessi sospetti ai path critici. Audit e logging servono a vedere tentativi di accesso anomali, non solo il successo dell’attacco. In hosting condiviso, pattern ripetuti di creazione/cancellazione di symlink in aree temporanee sono un segnale utile.

Hardening del filesystem e dei mount

Le opzioni di mount non risolvono tutto, ma riducono parecchio il rischio operativo. Su aree come /tmp e /var/tmp conviene valutare nosuid, nodev e, dove compatibile con i servizi, noexec. Non bloccano le race condition sui symlink, ma limitano il danno se un file malevolo finisce nel posto sbagliato.

Inoltre è importante distinguere fra directory realmente condivise e directory che dovrebbero essere private per ogni utente. Le home degli utenti non devono diventare punti di transito per processi di sistema che operano come root, se non con controlli robusti e ben documentati.

Quando il filesystem lo supporta e il flusso applicativo lo consente, valuta anche policy che riducano la possibilità di seguire symlink in aree sensibili. Il dettaglio dipende dalla distro e dal tipo di storage, quindi qui non serve ricetta universale: serve verificare quali opzioni sono disponibili sul tuo kernel e sul tuo layout.

cPanel, Apache, PHP e il problema dei path dinamici

Molti incidenti nascono non nel pannello in sé, ma nelle componenti attorno: Apache, PHP-FPM, cron, script di deploy, backup e restore. Il pannello spesso orchestra, ma il rischio si materializza nel momento in cui un servizio legge o scrive un file su un percorso che può essere alterato.

Con PHP e applicazioni web il problema si presenta spesso in upload, cache, sessioni, file temporanei e log applicativi. Se il web server o il PHP handler hanno permessi eccessivi, un utente può cercare di agganciare un symlink a un target esterno al proprio spazio. Con Apache la configurazione dei document root, delle alias e dei percorsi di log va tenuta sotto controllo: un log o una directory condivisa mal configurata può diventare un punto di pivot.

In cPanel, la prudenza deve essere massima su script personalizzati in /usr/local/cpanel/scripts, hook, plugin e cron che girano con privilegi alti. Ogni volta che uno di questi componenti prende in input un path proveniente da un utente o da un file modificabile dall’utente, la domanda corretta non è “il path esiste?”, ma “può essere sostituito fra verifica e uso?”.

Controlli operativi da fare subito

Per capire se sei esposto, parti da osservazione e inventario, non da modifiche alla cieca.

1. Individua i processi privilegiati che accedono a path scrivibili dagli utenti. Cerca job di backup, rotazione log, import/export, script custom e hook del pannello.
2. Verifica quali directory condivise contengono file o link sospetti. Controlla temp, cache, upload e aree di staging.
3. Controlla i permessi delle directory critiche e la presenza di sticky bit o altre protezioni dove servono.
4. Esamina i log del web server, di PHP-FPM e del sistema per accessi anomali, errori di permesso o path non attesi.
5. Conferma che i servizi non girino con privilegi inutilmente alti e che i file di configurazione non siano scrivibili da utenti non fidati.

Per esempio, una ricognizione di base sui permessi e sui link nelle aree più sensibili può partire così:

find /tmp /var/tmp /home -xdev -type l -ls 2>/dev/null | head -200

Il risultato non dice tutto, ma ti mostra subito se hai una popolazione anomala di symlink in zone esposte. Se vuoi restringere il campo agli oggetti modificati di recente, puoi incrociare con le date e con i proprietari. Il criterio utile è semplice: in una directory che dovrebbe essere temporanea o user-owned, i symlink non devono essere numerosi, opachi o creati da account inattesi.

Misure di configurazione da preferire

Le misure più efficaci, in ordine pratico, sono queste:

1. ridurre i privilegi dei servizi che operano su filesystem condivisi;
2. evitare che root scriva in path controllabili dall’utente;
3. usare directory private per cache e temporanei delle applicazioni;
4. proteggere i percorsi di staging e i processi di deploy con ownership coerente;
5. aggiornare regolarmente cPanel, kernel, web server, PHP e componenti correlati;
6. auditare i plugin e gli script custom che manipolano file.

La parte più sottovalutata è la quarta: staging e deploy. Molti ambienti hosting hanno script che copiano file da una directory all’altra, magari come root, magari dopo una validazione superficiale. Se uno di quei path è alterabile, la race condition è dietro l’angolo.

Logging, audit e detection

Non basta prevenire. Devi anche poter capire quando qualcuno ci sta provando. Le tracce utili sono:

• creazione e rimozione ripetuta di symlink in directory temporanee;
• errori di permesso anomali su file che dovrebbero essere regolari;
• accessi a file fuori dal perimetro usuale di un account;
• operazioni di scrittura verso path inattesi da parte di processi privilegiati;
• comportamenti non coerenti nei log di Apache, PHP-FPM, cron e sistema.

Se hai auditd o un sistema EDR compatibile, monitora i path ad alto rischio. L’obiettivo non è registrare tutto, ma avere segnali affidabili su accessi a file sensibili e su modifiche sospette a directory condivise. In ambienti cPanel molto popolati, il rumore è alto: serve una baseline per distinguere il normale dal sospetto.

Quando il problema è nel codice o nello script custom

Molte vulnerabilità pratiche non nascono dal pannello ma da script proprietari installati sopra cPanel. Il pattern pericoloso è sempre lo stesso: controllo del file separato dall’apertura, uso di nomi in /tmp prevedibili, cleanup incompleto, e fiducia eccessiva nel proprietario del file.

Se gestisci codice custom, la correzione deve essere strutturale:

1. apertura sicura dei file senza seguire symlink dove non necessario;
2. nomi temporanei unici e non prevedibili;
3. directory temporanee private per utente o processo;
4. validazione del path dopo l’apertura, non prima;
5. nessuna operazione privilegiata su input controllabili dall’utente senza un controllo forte.

Se non puoi correggere subito il codice, la mitigazione più veloce è spostare i temporanei fuori dalle directory condivise, ridurre i privilegi del processo e mettere controlli lato filesystem e permessi. Non è elegante, ma spesso è il modo corretto per abbassare il rischio in produzione mentre prepari il fix.

Rollback e gestione del cambiamento

Ogni hardening che tocchi path, mount o permessi va trattato come change controllato. Prima fai backup della configurazione e annota lo stato attuale. Dopo ogni modifica, verifica che web, mail, backup, cron e pannello continuino a funzionare. Se un servizio si rompe, devi poter tornare indietro rapidamente.

Il rollback deve essere chiaro: ripristino di permessi, rimozione di mount option incompatibili, revert di config del servizio, annullamento di script custom o hook introdotti nel tentativo di mitigazione. Il blast radius è reale: una modifica troppo aggressiva su /tmp o sulle home può fermare applicazioni legittime, job di manutenzione o il provisioning degli account.

Checklist operativa minima

1. mappa i processi privilegiati che toccano path scrivibili dagli utenti;
2. identifica directory temporanee, cache e staging condivisi;
3. verifica permessi, ownership e presenza di symlink anomali;
4. riduci i privilegi dove possibile;
5. separa i path sensibili da quelli user-writable;
6. attiva logging e audit sui file critici;
7. testa il rollback prima di applicare hardening più restrittivi.

Se devi scegliere una sola priorità, scegli questa: impedire che un processo privilegiato segua o usi un symlink in un percorso controllabile da un utente non fidato. Tutto il resto è contorno di riduzione del rischio.

Cosa aspettarsi dopo il fix

Dopo l’hardening corretto, dovresti vedere meno eventi anomali su path temporanei, meno errori di permesso “strani”, nessun accesso a file fuori perimetro da parte di processi di sistema e una riduzione concreta della superficie di escalation locale. Se non cambia nulla nei log e nei pattern di accesso, probabilmente hai protetto il punto sbagliato oppure il vettore passa da uno script custom non ancora mappato.

La verifica utile non è “sembra a posto”. È: i processi privilegiati non seguono più path alterabili, i file sensibili non sono più raggiungibili tramite directory condivise, e il rollback è pronto se una mitigazione rompe un flusso legittimo.

Assunzione: l’ambiente è cPanel/WHM su Linux recente con servizi web e script custom che operano su filesystem condivisi, e l’obiettivo è ridurre il rischio senza interrompere il servizio.

Riferimenti operativi da consultare

Per chi deve chiudere il lavoro in modo serio, le fonti da leggere sono la documentazione del kernel e delle mount option, le note di sicurezza di cPanel/WHM, la configurazione del web server e del PHP handler, oltre ai log locali del sistema. Se hai un team interno, vale la pena trasformare questa checklist in una baseline di hardening ripetibile per tutti i server hosting.

In pratica: meno fiducia nel path, meno privilegi, più controllo atomico, più audit. È questa la combinazione che rende le race condition sui symlink molto più difficili da sfruttare in un ambiente cPanel.