The Pulse

PWN Research segnala un’evasione da Firecracker con accesso root all’host, eseguita senza jailer

PWN Research descrive un’evasione da una microVM di Firecracker che ha reindirizzato un thread di CPU virtuale in esecuzione ed eseguito codice nel processo host. Nella dimostrazione Firecracker era eseguito come root senza il suo jailer, u

AI.info Team · Scritto con l’IA · verificato · 2026-11-07

Firecracker dovrebbe confinare il codice non attendibile all’interno di una microVM. PWN Research afferma che i suoi ricercatori hanno oltrepassato questo confine e sono riusciti a eseguire codice come root sull’host. Nella configurazione testata, però, Firecracker era eseguito direttamente come root e non disponeva di un jailer.

Seguire una pagina guest fino al VMM

I ricercatori descrivono il lavoro come una continuazione di PwnEscape Part 1. Ogni CPU virtuale ha un thread host che entra in KVM per eseguire il guest e torna a Firecracker quando userspace deve gestire un evento. Mentre il thread esegue KVM_RUN, il kernel host conserva i suoi registri userspace salvati in una struttura chiamata pt_regs. I ricercatori affermano di aver usato il frame salvato per scegliere il punto in cui Firecracker avrebbe ripreso l’esecuzione dopo il ritorno da KVM.

Sono partiti da una pagina guest contenente un nonce riconoscibile, quindi hanno cercato tra le radici EPT candidate una traduzione che portasse a quella pagina. La verifica del nonce ha collegato una traduzione proposta a una porzione di memoria controllata dai ricercatori. La ricerca ha prodotto due candidate e la validazione delle tabelle delle pagine annidate le ha ridotte a una sola radice EPT. Dall’indirizzo host della pagina guest, il reverse mapper ha ricavato uno spazio di indirizzamento del processo host e l’indirizzo virtuale al quale compariva quella pagina.

Individuare il thread vCPU in esecuzione

I ricercatori hanno poi identificato l’eseguibile di Firecracker, ne hanno ricavato l’offset di caricamento e hanno cercato il frame dei registri salvati del thread vCPU in esecuzione. Hanno verificato il frame candidato rispetto alla richiesta KVM_RUN, all’indirizzo dell’istruzione di Firecracker validato e alle tabelle delle pagine host ricavate. La ricerca ha lasciato un solo frame candidato, che hanno passato a un helper finale. Quest’ultimo ha ripetuto le verifiche su codice, frame e stack prima di apportare modifiche.

Un marcatore conferma l’esecuzione sull’host

Come prova del controllo ottenuto, i ricercatori hanno scelto una scrittura su stderr di Firecracker. Una scrittura sulla porta seriale del guest ha provocato il ritorno del thread vCPU da KVM_RUN, dopodiché Firecracker ha eseguito l’operazione di scrittura selezionata. Il runner host ha catturato il marcatore e la pagina afferma che l’output conteneva esattamente otto byte, incluso il carattere finale di nuova riga.

Dopo l’attivazione, Firecracker è rimasto in esecuzione, SSH sul guest ha risposto e l’helper aveva ripristinato tutte e tre le parole temporanee dello stack. I ricercatori riferiscono anche che una nuova passata di validazione, eseguita senza modifiche alla memoria, ha superato le verifiche dopo il ripristino.

La configurazione con esecuzione come root limita la portata del risultato

Il bersaglio era Firecracker v1.16.1 su x86-64, con kernel host 7.0.0-1011-aws e kernel guest 6.18.44+. Firecracker era eseguito direttamente come root tramite systemd-run e la configurazione testata non disponeva di un jailer. La pagina afferma che le misure di contenimento di Firecracker in produzione comprendono la riduzione dei privilegi e la limitazione del processo tramite namespace e seccomp. Una distribuzione che usa questi controlli, scrivono i ricercatori, richiede una valutazione separata dei privilegi e delle risorse disponibili dopo la compromissione del VMM.