Exploitability of Heap Vulnerabilities

1

Sto studiando le vulnerabilità della sicurezza della memoria e ho notato che nelle applicazioni non-browser (ad esempio il kernel Linux) le voci dei dettagli CVE per le vulnerabilità use-after-free elencano quasi sempre gli UAF come errori di denial of service, non l'esecuzione di codice remoto errori. Citano persino gli UAF ogni volta che un denial of service viene menzionato nel report (cioè dicono tutti qualcosa come "questa vulnerabilità può essere usata per causare un Denial of Service (use-after-free)"). C'è qualche caso particolare che fa sì che le UAF conducano all'esecuzione di codice nel contesto di un'applicazione browser ma non in un altro contesto? Ho sentito che gli errori relativi all'heap (inclusi gli UAF) tendono ad essere inaffidabili a causa del layout sconosciuto dell'heap al momento dello sfruttamento a meno che l'hacker non abbia un metodo per "massaggiare" il layout dell'heap, di cui il metodo più comune sta usando Javascript o qualche altro linguaggio di scripting. Questo è il motivo (l'uso di Javascript) il motivo per cui le vulnerabilità use-after-free vengono definite vulnerabilità di esecuzione del codice nel contesto di un browser, ma una negazione del servizio nel contesto di altri programmi?

Su una nota correlata, ho sentito dire che la presenza di un qualche tipo di ambiente di scripting (Javascript, Flash, ecc.) è richiesta in molti casi per sfruttare tutti i bug infallibili (ad esempio perdere un puntatore per sconfiggere ASLR) quando l'utente malintenzionato non ha ancora accesso al computer e il programma attaccato non può essere interagito a distanza, ad esempio quando un utente malintenzionato tenta di sfruttare una vulnerabilità del browser. È vero?

Infine, che tipo di programmi hanno la più alta percentuale di attacchi con stringhe di formato? Ho provato a cercarli per una varietà di programmi comunemente usati (diversi browser, openssh, openvpn, openssl, Adobe Flash, il motore Javascript V8 e vari server http), e ho potuto trovare solo due formato vulnerabilità delle stringhe in tutto, una delle quali potrebbe essere utilizzata solo per leggere la memoria e non eseguire una scrittura arbitraria. Poi ho cercato su google "format string cve details" e quasi ogni singolo risultato sulle prime pagine era una vulnerabilità in PHP. I linguaggi di scripting sono particolarmente vulnerabili per formattare le vulnerabilità delle stringhe?

    
posta John 31.01.2017 - 09:10
fonte

0 risposte