Prova di concetto per CVE-2024-54756, una vulnerabilità che ho trovato nel motore di scripting ZScript di GZDoom.
Una proof of concept per una vulnerabilità di esecuzione di codice arbitrario che ho trovato nella funzionalità ZScript di GZDoom (https://github.com/zdoom/gzdoom). Un attaccante può condividere un file PK3 contenente un file sorgente ZScript malevolo e ottenere accesso al PC della vittima.
Un grande ringraziamento a Rachael e Agent Ash del team di sviluppo di GZDoom per le loro risposte tempestive, e a loro e agli altri sviluppatori di GZDoom per aver risolto rapidamente la questione!
Confermato funzionante per 4.13.0 e 4.13.1, e probabilmente funziona anche per versioni precedenti. Fate attenzione a chiunque vi dica di tornare alla versione 4.13.1 o inferiore per poter giocare al loro WAD.
Questa PoC funziona solo su Linux, ma la vulnerabilità probabilmente esiste anche su Windows. Non testata su ZDoom o LZDoom, ma la vulnerabilità potrebbe esistere anche lì.
La vulnerabilità è stata segnalata agli sviluppatori prima della pubblicazione di questa PoC e non dovrebbe più essere presente nella versione 4.13.2. Per quanto ne so, questa versione non include modifiche sostanziali.
Questa PoC è creata e rilasciata a scopo educativo, affinché gli sviluppatori di motori di gioco/scripting possano capire come possono nascere le vulnerabilità e affinché i giocatori possano capire come può apparire una mod malevola. Non sono responsabile per qualsiasi uso improprio di questa PoC. Per favore, non usatela per compromettere i PC dei vostri compagni di gioco; è illegale (non dovreste aver bisogno che ve lo dica io), ed è un atto particolarmente meschino prendere il controllo del computer di qualcuno attraverso un videogioco.
Per usare questa PoC, scaricate questo repository e create un file PK3 (che è in realtà un file zip con estensione .pk3) contenente zscript.zs e MAPINFO:
git clone https://github.com/Chainmanner/GZDoom-Arbitrary-Code-Execution-via-ZScript-PoC
cd GZDoom-Arbitrary-Code-Execution-via-ZScript-PoC
zip PoC.pk3 zscript.zs MAPINFO
Il payload predefinito è eseguire una reverse shell su localhost alla porta 1337. Avviate il listener:
nc -nvlp 1337
Eseguite la PoC in questo modo:
gzdoom -iwad <your-doom-o-freedoom-wad> -file PoC.pk3
Se ha funzionato, ora dovreste avere una reverse shell verso voi stessi.
Questa PoC è solo per Linux. Potrebbe non funzionare al primo tentativo; provate di nuovo fino a quando non funziona.
NOTA: Questa è la mia prima stesura di exploit e sto ancora lavorando sulla mia abilità di fare stesure a basso livello. Inoltre, ho fatto gran parte del debug con GDB, e sfortunatamente non ho avuto la buona idea di salvare alcuni dump di memoria per illustrare meglio la mia spiegazione. Scusate! La mia prossima stesura sarà migliore, lo prometto.
GZDoom è un source port di Doom progettato per prestazioni ed estensibilità. Grazie alle sue potenti funzionalità, sono stati creati molti WAD, mod e persino conversioni totali commerciali fantastici. Sfortunatamente, dove c'è complessità, c'è l'opportunità per vulnerabilità, e in questo caso ce n'erano due presenti nel motore di scripting ZScript che hanno permesso il sorgere di una catena di exploit completa.
Questo attacco sconfigge ASLR e aggira la necessità di sconfiggere i canarini di stack. Non credo che CFI di Clang o shadow stack avrebbero aiutato qui.
La prima e più importante vulnerabilità era nel modo in cui venivano gestiti gli array enormi. Se allocate un array abbastanza piccolo, la regione di memoria allocata tende ad essere riempita con zeri ed è adeguatamente separata dagli altri oggetti; nessuna informazione può essere ottenuta leggendo memoria non inizializzata, e nessun oggetto si sovrappone all'array. Tuttavia, se allocate un array enorme - diciamo, 1073741823 parole a 32 bit o più - sarete in grado di leggere e scrivere fino a 4 GiB di memoria potenzialmente non inizializzata a partire dal punto di partenza dell'array, permettendo all'attaccante di modificare direttamente altri oggetti e sconfiggere ASLR trovando indirizzi con offset conosciuti. Inoltre, qualsiasi altro array creato dopo questo punto si sovrapporrà con quello enorme.
La seconda vulnerabilità era nei permessi della mappa di memoria. Per prestazioni più veloci, il codice ZScript viene compilato JIT in bytecode x86 o x86-64 quando possibile. Per avere questo, il codice deve essere scritto in una regione di memoria, e quella regione di memoria deve essere eseguita. Tuttavia, la regola W^X afferma che una regione dovrebbe essere scrivibile o eseguibile, ma non entrambe. Se entrambe sono applicate contemporaneamente (invece di rendere la regione scrivibile, scrivere il codice, e poi renderla eseguibile e non scrivibile), allora un attaccante con una primitiva di scrittura arbitraria sarà in grado di elevarla a esecuzione di codice arbitrario; possono scrivere shellcode e saltarci modificando, ad esempio, l'indirizzo di ritorno sullo stack (supponendo che l'attaccante non abbia una primitiva di esecuzione arbitraria). Se guardate le mappature di memoria di GZDoom mentre è in esecuzione, potete vedere ci sono diverse regioni RWX:
7fcd19700000-7fcd19800000 rwxp 00000000 00:00 0
7fcd1a100000-7fcd1a200000 rwxp 00000000 00:00 0
7fcd1eb00000-7fcd1ec00000 rwxp 00000000 00:00 0
Quindi se sono disponibili primitive di scrittura arbitraria e di esecuzione arbitraria, e l'attaccante sa dove si trova una regione RWX, può scrivere shellcode arbitrario ed eseguirlo. Rendere queste regioni RW- durante la scrittura del codice compilato JIT e poi R-X quando pronto per l'esecuzione fermerebbe questa PoC, ma non fermerebbe un attaccante dall'ottenere l'esecuzione di codice, ad esempio, modificando dati sullo stack (ROP) o sull'heap.
Inoltre, c'è un gadget utile. Ricordate che quando si alloca un array enorme, qualsiasi altro array creato dopo si sovrapporrà? Questo include array di puntatori a oggetti. Proprio come gli oggetti C++, gli oggetti ZScript possono contenere variabili e puntatori a funzioni. Supponiamo di avere questo oggetto:
class WeirdObject
{
uint one;
uint two;
uint three;
uint four;
Function<clearscope void()> funcptr;
}
Se creiamo un array contenente un puntatore a un'istanza di WeirdObject, allora l'attaccante può cambiare il puntatore dove vuole usando l'array enorme e modificare i dati puntati accedendo ai campi dell'oggetto, dandoci una primitiva di lettura/scrittura arbitraria che va oltre l'heap. I puntatori in ZScript vengono controllati per assicurarsi che non siano nulli, ma non per assicurarsi che siano sensati.
La presenza di un puntatore a funzione ci dà anche una primitiva di esecuzione arbitraria; questo, tuttavia, è un po' meno diretto, richiedendo la creazione di un VMFunction falso per soddisfare la macchina virtuale. Non appena una chiamata a una funzione ZScript viene introdotta nel codice exploit, quel codice non viene più compilato JIT. Funziona ancora, ma diventa un po' più complesso da debuggare e sfruttare. Potrebbe esserci un modo migliore per fare questa parte, ma non ho studiato abbastanza gli interni di GZDoom per conoscerlo.
Una cosa da notare: WeirdObject ha variabili membro ereditate, quindi il primo membro inizia all'offset 0x28.
Quindi, ora abbiamo i seguenti strumenti:
Come li incateniamo per creare un exploit?