initstring/lxd_rootEscalation dei privilegi Linux tramite LXD
I membri del gruppo locale lxd sui sistemi Linux hanno numerose strade per elevare i propri privilegi a root. Questo repository contiene esempi di exploit locali completamente automatizzati. Una spiegazione dettagliata della vulnerabilità e un'analisi dell'exploit è disponibile nel mio blog qui.
Gli exploit seguenti non sono evasioni dal container, ma exploit locali che sfruttano i container e prendono di mira il sistema operativo host. È richiesto un accesso a bassi privilegi all'ambiente host per uno sfruttamento riuscito.
Credo che la mia strategia con la versione 2 dell'exploit sia unica, e sia stata abbastanza interessante (almeno per me) da meritare una spiegazione dettagliata nel blog linkato sopra.
lxd_rootv1.sh monta il filesystem / dell'host in un container, dove l'utente a bassi privilegi dell'host ha accesso root. Questo accesso root si ripercuote sull'host, permettendo all'utente corrente di essere aggiunto al file /etc/sudoers. Questo è stato sfruttato da altri prima di me.lxd_rootv2.py monta il socket UNIX privato di systemd dell'host in un container e poi di nuovo all'host tramite i dispositivi proxy di LXD. Questi dispositivi proxy hanno privilegi di root, e passano le loro credenziali durante le comunicazioni socket, al contrario delle credenziali dell'utente a bassi privilegi che li avvia. Questo viene abusato per creare un servizio systemd temporaneo che aggiunge l'utente corrente al file /etc/sudoers.Entrambi gli exploit richiedono un container, quindi creane prima uno. Poi, esegui l'exploit dal sistema operativo host con il nome del container come primo argomento.
# Exploit con v1
$ bash lxd_rootv1.sh <nome container>
# Exploit con v2
$ python3 lxd_rootv2.py <nome container>
Prima che mi imbattessi in questi problemi, non esisteva nulla nella documentazione ufficiale di LXD che avvertisse gli utenti che il gruppo lxd era pericoloso. Chiunque seguisse le linee guida ufficiali per configurare LXD avrebbe aggiunto il proprio account a questo gruppo prima di distribuire il primo container. Ho aperto un bug con Canonical per esprimere le mie preoccupazioni - puoi leggere l'intera discussione qui. Il team di LXD ha rapidamente apportato modifiche alla documentazione, che ora afferma chiaramente che questo gruppo dovrebbe essere dato solo a coloro di cui ci si fida con l'accesso root.
Come sempre, interagire con le persone di Canonical tramite il loro bug tracker è stata un'esperienza davvero piacevole. Vorrei ringraziarli per il loro tempo e per la considerazione attenta che hanno dato alle mie idee. Raccomando vivamente ad altri ricercatori di sicurezza di portare loro direttamente i problemi in questo modo.
Non sono la prima persona a sfruttare LXD. Questo è stato sollevato come preoccupazione in diversi ticket GitHub risalenti al 2016:
Quel primo link è la prima persona (simpoir) ad aver identificato questo rischio, per quanto ne so.
@reboare ha scritto un bel blog sullo sfruttamento di LXD usando lo stesso metodo del mio exploit v1, molto prima di me:
Grazie alle persone di LXD per aver creato uno strumento davvero interessante. Personalmente uso LXD e mi piace molto. Non penso che questo sia un ostacolo all'uso di LXD, penso solo che sia molto importante comprendere il potenziale rischio quando si aggiungono utenti al gruppo lxd.
Non esiste una correzione ufficiale per nessuna di queste vulnerabilità. Chiunque usi LXD dovrebbe essere consapevole che aggiungere utenti al gruppo lxd equivale essenzialmente a trasformarli in root.
Se stai usando LXD su un host a utente singolo, come un desktop, potrebbe essere meglio non usare affatto il gruppo lxd ed eseguire sudo quando hai bisogno di comunicare con l'API.
Per ambienti condivisi con più persone che lavorano sui container, potrebbe essere meglio creare ambienti annidati. Ogni singolo utente del gruppo LXD sarà in grado di sfruttare il proprio ambiente ma dovrà poi lavorare di più per uscire da quel container per sfruttare gli altri.