Ho seguito un sacco di tutorial sullo sfruttamento delle vulnerabilità UAF, ma non è mai stato spiegato come trovare e rilevare le vulnerabilità UAF in JavaScript o HTML (cioè con un'analisi statica).
La mia domanda è: come decodificare le funzioni JavaScript per vedere se un oggetto è stato liberato, da questa funzione, e con quale funzione posso usarlo di nuovo (dopo che è stato liberato) per provocare un uso dopo un problema gratuito?
Sebbene JavaScript e HTML come lingue siano privi di use-after-free by design (a causa della mancanza di accesso alla memoria di basso livello), possono ancora essere utilizzati per sfruttare UAF nei motori che interpretano ed eseguono JavaScript / HTML .
Ecco come si trovano le vulnerabilità UAF:
Per iniziare, puoi studiare segnalazioni di bug pubbliche (ad es. Chrome di criticità di livello medio / alto / critico ( linee guida sulla severità ), Firef bug ad alta / critica di ox ( linee guida sulla severità ), qualsiasi CVE). JavaScript è un linguaggio altamente dinamico, a volte puoi fare cose che i progettisti / implementatori di una determinata funzione non hanno previsto o aspettato, con conseguenti vulnerabilità della sicurezza (ad esempio un serializzatore JSON che non ha tenuto conto del fatto che i callback personalizzati possono modificare l'input ). La maggior parte degli errori non si trova nel motore JavaScript stesso, ma nell'implementazione delle API disponibili (ad esempio DOM non fa parte di JavaScript).
Se disponibile, utilizza AddressSanitizer perché rende più facile rilevare e classificare il tipo di bug di memoria. Puoi crearlo dal sorgente, o usare i binari pre-costruiti (vedi ad esempio Firefox o Chrome ).
Nota: Trovare l'UAF è il passo più facile, in realtà sfruttarlo è molto più difficile. I programmi moderni utilizzano ogni sorta di misure preventive per contrastare le vulnerabilità (ad esempio ASLR , stack non eseguibili, stack / heap protectors, < a href="https://wiki.ubuntu.com/Security/Features"> e altro ).
La tua domanda non è corretta a molti livelli.
Innanzitutto, JavaScript è il linguaggio gestito dalla memoria. Cioè, uno sviluppatore non libera mai la memoria. Invece, l'interprete JavaScript gestisce tutto ciò. Quindi, se l'interprete JavaScript è scritto correttamente, non ci possono essere vulnerabilità use-after-free. Pertanto, l'analisi statica di JavaScript mai trova una vulnerabilità use-after-free.
HTML non ha davvero un concetto di gestione della memoria per discutere anche di use-after-free.
Per quanto riguarda il reverse engineering JavaScript, ciò non ha molto senso. JavaScript non è compilato in modo da avere sempre la fonte disponibile. Forse il JavaScript è stato offuscato, ma hai ancora il codice, è solo difficile da leggere.
Leggi altre domande sui tag javascript exploit exploit-development use-after-free