themalwareguardian/cve-2025-70330Bug di parsing di file di Easy Grade Pro 4.1 utilizzato come esempio didattico per mostrare come i principianti possono iniziare la ricerca di vulnerabilità attraverso il reverse engineering.
Un esempio educativo creato per mostrare ai principianti che la ricerca di vulnerabilità tramite reverse engineering è possibile fin dall'inizio.
Questo repository nasce dalla necessità di avere un esempio semplice che possa essere utilizzato quando si insegnano ai principianti che iniziano la ricerca di vulnerabilità, specialmente a coloro che sono interessati al reverse engineering.
Dopo aver completato un corso, una sessione di formazione o un master in exploit binario o analisi binaria, molti studenti pensano che la ricerca di vulnerabilità reale sia qualcosa di molto al di là del loro livello. Di solito associano il reverse engineering a argomenti molto avanzati come vulnerabilità del kernel, exploit di browser, ricerca firmware o obiettivi moderni complessi, e per questo pensano di non essere ancora pronti. In pratica, il problema non è la mancanza di conoscenza, ma la mancanza di un punto di partenza realistico.
Volevo un esempio che potesse mostrare che con le competenze apprese durante un corso base è già possibile prendere un programma reale, capire come funziona, provocare un crash e identificare un vero bug.
Questo repository è esattamente quel tipo di esempio. Non si tratta di trovare una vulnerabilità complessa. Si tratta di mostrare che i principianti possono iniziare da qualcosa di piccolo, riproducibile e comprensibile, e comunque fare vera ricerca di vulnerabilità.
Questo repository è direttamente correlato al mio talk "The Path That Leads to Your First CVE", in cui spiego che ci sono molteplici modi per entrare nel mondo della ricerca di vulnerabilità e che ogni persona di solito segue un percorso diverso a seconda dei propri interessi.
Alcune persone iniziano con l'audit del codice sorgente, altre con il reverse engineering, altre con la sicurezza web e altre con la ricerca tecnologica. Tutti questi percorsi sono validi, ma la parte importante è capire che ogni area ha anche punti di ingresso adatti ai principianti.
Esempi di percorsi per principianti includono:
Questi tipi di obiettivi possono sembrare basilari, ma insegnano le stesse competenze fondamentali necessarie in seguito quando si lavora su sistemi complessi.
Questo repository rappresenta uno di quei percorsi per principianti nel campo del reverse engineering.
La vulnerabilità documentata qui è stata trovata analizzando un'applicazione vecchia, capendo come viene analizzato il suo formato file e identificando un errore di programmazione che porta a un crash. L'impatto stesso non è complesso, ma il processo è reale, riproducibile e utile per imparare come funziona effettivamente la ricerca di vulnerabilità.
Questo è il tipo di esempio che uso quando spiego "The Path That Leads to Your First CVE", per mostrare che il reverse engineering è un percorso valido fin dall'inizio e che iniziare con obiettivi semplici non solo è accettabile, ma spesso è il modo migliore per imparare.
Quando si inizia, le applicazioni moderne sono spesso troppo complesse. Usano protezioni, mitigazioni e codebase difficili da capire senza molta esperienza. I vecchi software sono diversi.
Le applicazioni legacy non sono state scritte con le moderne pratiche di sicurezza in mente. Spesso contengono semplici bug di parsing, operazioni di memoria non sicure ed errori logici che possono essere compresi con competenze di reversing di base. Questo li rende perfetti per imparare.
Con un programma vecchio puoi: fare reverse del binario, capire il formato file, provocare un crash, analizzare il crash, localizzare il bug, documentare il problema e segnalare la vulnerabilità. In altre parole, impari le competenze fondamentali di cui ogni ricercatore di vulnerabilità ha bisogno.
Questo è esattamente ciò di cui parla questo esempio.
Questo esempio è importante perché mostra qualcosa di molto semplice:
Se ti piace il reverse engineering, puoi seguire quel percorso fin dall'inizio. Potrebbero volerci anni per padroneggiarlo, ma non devi aspettare anni per iniziare a fare un lavoro reale.
La vulnerabilità (CVE-2025-70330) riguarda la logica di parsing dei file di Easy Grade Pro 4.1 durante il caricamento di file di registro .EGP proprietari.
L'applicazione ricostruisce le strutture interne del registro leggendo campi a posizione fissa dal file e utilizzando quei valori come offset all'interno del buffer del file caricato. Questi offset vengono successivamente utilizzati per calcolare le dimensioni in memoria e per copiare dati in buffer allocati dinamicamente.
In condizioni normali, il file supera diversi controlli strutturali prima che il parsing continui. Tuttavia, una volta che questi controlli riescono, il parser si fida dei valori di offset memorizzati nel file senza verificare che rimangano entro i limiti del buffer caricato.
Modificando byte specifici all'interno di un file .EGP altrimenti valido, è possibile corrompere questi calcoli interni degli offset. Quando il parser utilizza successivamente questi valori, tenta di leggere memoria al di fuori della regione valida del file, il che provoca una violazione di accesso e un crash dell'applicazione.
Questa condizione corrisponde a una lettura fuori dai limiti (CWE-125), che porta a un denial-of-service locale quando il file manipolato viene aperto.
Il formato file .EGP viene analizzato utilizzando un approccio basato su offset. Invece di elaborare il file in modo sequenziale, il parser legge strutture interne che contengono offset di inizio e fine che descrivono dove dovrebbero trovarsi blocchi di dati specifici all'interno del file.
Questi offset vengono utilizzati per calcolare la dimensione di una regione di memoria e per copiare dati dal buffer del file caricato in memoria allocata di recente.
La logica vulnerabile può essere riassunta come:
size = offset_end - offset_start + 1
buffer = calloc(1, size)
memcpy(buffer, file_buffer[offset_start - base_offset], size)
Una volta che il file supera i controlli di validazione iniziali, il parser presume che gli offset memorizzati nel file siano validi. Non viene eseguita alcuna verifica per assicurarsi che il puntatore di origine calcolato rimanga all'interno del buffer del file caricato.
Se gli offset vengono manipolati in modo controllato, il parser potrebbe tentare di leggere memoria al di fuori della regione valida, causando una violazione di accesso durante l'operazione memcpy().
Non tutti i file .EGP malformati provocano il crash.
Il parser esegue diversi controlli di coerenza prima di raggiungere il percorso di codice vulnerabile. Se la struttura del file è troppo corrotta, l'applicazione interrompe il parsing precocemente e segnala che il registro è danneggiato.
Tuttavia, alcune modifiche mantengono le strutture interne sufficientemente coerenti da superare i controlli iniziali, pur producendo valori di offset errati in fasi successive del parsing.
Quando ciò accade, il parser raggiunge routine più profonde in cui questi offset vengono considerati affidabili e utilizzati in operazioni di copia in memoria, causando infine la lettura fuori dai limiti.
Il crash può essere innescato modificando un file .EGP valido e inserendo dati controllati a un offset specifico.
Il proof of concept funziona come segue:
Esempio di parametri utilizzati nel PoC:
Questa modifica mantiene il file sufficientemente valido strutturalmente da superare i controlli iniziali, ma corrompe i calcoli interni degli offset utilizzati successivamente dal parser, causando infine il crash dell'applicazione.
Quando il file malformato viene aperto sotto un debugger, l'applicazione crasha durante un'operazione di copia della memoria.
L'eccezione osservata è una violazione di accesso causata da una lettura di memoria non valida.
Durante il debugging, il puntatore non valido utilizzato da memcpy() ha origine dai calcoli degli offset derivati dalle strutture del file analizzate. Quando questi offset fanno riferimento a memoria al di fuori del buffer del file caricato, il puntatore di origine punta a un indirizzo non mappato, causando il crash.
Ciò conferma che la vulnerabilità è causata dalla mancanza di validazione dei limiti durante il parsing del file.
Questa vulnerabilità riguarda un prodotto giunto al termine del ciclo di vita che non è più mantenuto dal fornitore.
Il problema è documentato a scopo educativo e di ricerca, e per fornire ai principianti un esempio concreto di come il software possa essere analizzato passo dopo passo per comprendere come appaiono i bug e come vengono trovate le vulnerabilità reali.