Non ho familiarità con Java, quindi questa potrebbe essere una domanda stupida.
In un programma C posso trovare buffer overflow o un exploit basato su ROP per eseguire codice personalizzato. Come è fatto nel contesto di Java? È persino possibile? Nelle stringhe Java o altri tipi di dati sono tutti limitati e quindi la sovrascrittura della memoria non è possibile. Che dire del tipo di attacco ROP?
O più genericamente quali sono i tipici vettori di attacco per un programma Java?
Saresti molto fortunato a trovare un caso in cui puoi eseguire direttamente codice tramite un semplice errore di codifica in Java. È possibile che un bug nell'implementazione di JVM permetta la corruzione della memoria attraverso un codice benigno, ma nel peggiore dei casi è raro che raro.
Tuttavia, anche all'interno di JRE (OpenJDK) una parte delle librerie è scritta in C e quindi contiene vulnerabilità di corruzione della memoria quando viene utilizzata con dati non fidati. Rendering di un JPEG dannoso sarebbe l'esempio canonico.
Ci sono molti bug non correlati alla memoria, come l'iniezione (HTML, SQL, LDAP, intestazioni HTTP, ecc.), ma quelli in generale non ti porteranno direttamente all'esecuzione di codice in modalità remota.
Una situazione fin troppo comune è quando una pratica libreria esegue deliberatamente il codice remoto senza che venga deliberatamente abilitato dal programmatore dell'applicazione. Esempi forniti in Secure Coding Guidelines per Java SE (5.0) Linee guida 3-8 / INJECT-8 : Attenzione nell'interpretazione del codice non attendibile sono alcune delle funzionalità disponibili: API di scripting, LiveConnect, estensioni XSLT, Persistenza a lungo termine di componenti JavaBeans, Java Sound, RMI, LDAP e alcune implementazioni JDBC / SQL. Un'applicazione può caricare deliberatamente il codice mobile, che porta a un altro mondo.
La risposta breve sarebbe "tutto il resto", ma non includendo i tipi semplicistici di errori derivanti dallo sfruttamento dei buffer overflow della memoria grezza. Esistono molti altri modi in cui la memoria può essere utilizzata in modo errato senza sovraccaricare un buffer.
Un esempio che potrebbe essere classificato come un problema di buffer overflow in java essere se l'applicazione utilizzata try / catch per intercettare i buffer overflow tentati e di conseguenza di prenderne uno, scavalcato un codice importante. Potresti immaginare una scritta male funzione "checkpassword" che ha finito per restituire "successo" se è stata fornita una password con troppi caratteri.
Un'opzione sta sfruttando la JVM stessa - potrebbe essere possibile avere un codice java che fa sì che la macchina virtuale effettiva si "spezzi" ed esegua operazioni arbitrarie al di fuori della sandbox; ci sono stati tali exploit, anche se sembrano fare affidamento sull'invio della vittima di un codice java per l'esecuzione (cioè, in un contesto sandbox del browser), non sullo sfruttamento di programmi java casuali.
Un'altra opzione è identificare e abusare dei problemi logici nei programmi. Negli exploit C, uno scenario tipico consiste nell'utilizzare un controllo di confine errato come metodo per ottenere comportamenti totalmente indefiniti (come l'esecuzione di codice arbitrario) non correlati al controllo particolare; tuttavia, in assenza di ciò, alcuni controlli di limiti errati o problemi logici possono ottenere un percorso di codice che (involontariamente) si trova nel codice originale e fa ciò che vuoi.
E naturalmente tutte le gioie della complessità delle app multi-livello hanno possibili vettori di attacco - Iniezioni SQL se quell'app java si collega a un database, ecc.
I difetti di sicurezza comuni di Java includono:
I difetti che ho appena menzionato si applicano alle stesse applicazioni Java. Uno scenario comune è un'applicazione Web Java che può essere attaccata da client Web dannosi. Anche se la JVM stessa è sicura al 100%, le applicazioni possono avere i loro punti deboli.
Un altro scenario sono le applet Java. Questa è in realtà una situazione molto diversa, un'applet Java non attendibile è in esecuzione nel browser, all'interno di una sandbox, e sta tentando di uscire dalla sandbox. Qui la sicurezza della JVM stessa è fondamentale.
Leggi altre domande sui tag java vulnerability exploit known-vulnerabilities