Lo sviluppatore Gezine ha condiviso progressi concreti e misurabili sull’exploit denominato Y2JB, documentati tramite due schermate che mostrano sia l’esecuzione di parti della catena ROP sia lo stato dei registri.
Nella prima immagine si nota l’innesco di una porzione della catena ROP utilizzando determinati “oggetti” e gadget: questo indica che Gezine è riuscito a concatenare istruzioni già presenti nel binario per ottenere operazioni utili (letture di memoria e manipolazione di contesti), senza ricorrere a nuovo codice iniettato.
L’autore precisa che quella singola fase gli è costata circa un giorno di lavoro e che con maggiore routine l’operazione sarebbe potuta risultare più rapida, segno di una tecnica ormai consolidata ma ancora in fase di messa a punto.
Nella seconda schermata sono riportati gli indirizzi dei registri, con la nota che rdi, rsi, rdx, rcx, r8 e r9 sono “buoni”, cioè contengono valori coerenti e controllabili.
Questo è un dettaglio significativo: su architetture x86_64 (System V ABI) quei registri corrispondono ai primi sei argomenti che vengono passati a una funzione, quindi il fatto che risultino accessibili e impostabili suggerisce che Gezine può posizionare valori utili per chiamare funzioni già presenti nel programma o per impostare parametri di sistema.
In termini pratici, avere i registri sotto controllo è un passo cruciale verso il controllo del flusso di esecuzione, anche se non significa automaticamente esecuzione di codice arbitrario senza ulteriori primitive.
Dal resoconto emerge inoltre che Gezine ha ottenuto almeno una primitive di lettura/regolazione dello stato (come la capacità di leggere registri e indirizzi), e ha dimostrato la presenza di gadget utili per la costruzione della catena ROP.
Questo tipo di progresso tipicamente permette di passare dalle fasi di “information disclosure” (scoperta di indirizzi e registri) a fasi più avanzate come l’assemblaggio di una catena più lunga che esegua chiamate di sistema o invii parametri a funzioni critiche.
Tuttavia, dalle informazioni condivise non si evince che siano già state superate eventuali meccaniche di protezione presenti (ASLR, NX/DEP, stack canaries, eventuali meccanismi di integrità di controllo del flusso), né viene mostrata una prova di esecuzione di payload finale: si tratta quindi di un progresso tecnico rilevante ma ancora intermedio.
La documentazione tramite schermate è utile perché mostra tanto la riproducibilità del lavoro quanto lo stato effettivo dei registri e degli indirizzi coinvolti; sapere che i registri sono “buoni” aiuta a ridurre l’incertezza nella fase di progettazione della catena e ad accelerare i test.
Allo stesso tempo, Gezine non sembra aver pubblicato istruzioni operative dettagliate: i post mostrano lo stato dei test e alcune conferme tecniche, ma non forniscono una guida passo-passo che permetta a terzi di riprodurre l’exploit in modo immediato.
In termini di impatto, questi risultati indicano che l’exploit progredisce in modo metodico: si stanno costruendo e verificando primitive fondamentali (lettura di registri, individuazione dei gadget), e ogni conferma apre la strada a fasi successive di sviluppo.
Resta però importante sottolineare che tra avere registri controllabili e ottenere esecuzione persistente c’è ancora un lavoro significativo, e molte variabili legate all’ambiente e alle protezioni possono bloccare o rallentare la progressione.
Fonte: discord.com
 e primitive per futuri sviluppi. Aggiornamenti tecnici.){kind=link}