Java ha buffer overflow? Se sì, puoi darmi degli scenari?
Risposte:
Poiché le stringhe Java sono basate su array di caratteri e Java controlla automaticamente i limiti degli array, gli overflow del buffer sono possibili solo in scenari insoliti:
I linguaggi gestiti come Java e C # non presentano questi problemi, ma le macchine virtuali specifiche (JVM / CLR / ecc.) Che eseguono effettivamente il codice potrebbero.
A tutti gli effetti, no.
Java ha il controllo dei limiti dell'array che verificherà che non sia possibile accedere ai dati dall'area esterna all'array allocato. Quando si tenta di accedere a un'area che è oltre la dimensione dell'array, ArrayOutOfBoundsverrà generata un'eccezione.
Se si verifica un sovraccarico del buffer, è probabilmente dovuto a un bug nella Java Virtual Machine e, per quanto ne so, non è il comportamento previsto scritto nelle specifiche del linguaggio Java né nelle specifiche della Java Virtual Machine.
Sì e no. No, in quanto non puoi davvero creare per sbaglio aprirti a una vulnerabilità di overflow del buffer perché è un modello di memoria gestita. Tuttavia, possono esserci vulnerabilità di overflow del buffer in JVM e JDK. Vedi questo avviso di Secunia:
http://secunia.com/advisories/25295
Oppure vedere questi vecchi avvisi su diverse vulnerabilità JDK e JRE precedenti:
Le vulnerabilità di overflow di numeri interi e buffer nell'utilità di decompressione JAR "unpack200" di Java Runtime Environment (JRE) possono portare all'escalation dei privilegi https://download.oracle.com/sunalerts/1020225.1.html
Le vulnerabilità di overflow di interi e buffer in Java Runtime Environment (JRE) con applet di decompressione e applicazioni Java Web Start che utilizzano l'utilità di decompressione JAR "unpack200" possono consentire a un'applet o un'applicazione non attendibile di aumentare i privilegi. Ad esempio, un'applet non attendibile può concedere a se stessa le autorizzazioni per leggere e scrivere file locali o eseguire applicazioni locali accessibili all'utente che esegue l'applet non attendibile.
Sun ringrazia "regenrecht" lavorando con iDefense VCP ( http://labs.idefense.com/vcp/ ) e Chris Evans di Google per aver portato questi problemi alla nostra attenzione.
Sono state identificate diverse vulnerabilità in Sun Java Development Kit (JDK) e Java Runtime Environment (JRE). https://security.gentoo.org/glsa/200705-23
Una vulnerabilità non specificata che coinvolge un "uso errato delle classi di sistema" è stata segnalata dal team di sicurezza Fujitsu. Inoltre, Chris Evans del team di sicurezza di Google ha segnalato un overflow di numeri interi che ha provocato un overflow del buffer nel parser ICC utilizzato con i file JPG o BMP e una chiamata open () errata a / dev / tty durante l'elaborazione di determinati file BMP.
Un overflow del buffer nel senso stretto di sovrascrivere lo stack o l'heap stesso richiederebbe:
Un buffer overflow nel senso che il codice utilizza un buffer e il codice è responsabile dell'analisi corretta, ma è possibile non farlo. Ad esempio, potresti scrivere un parser XML e qualcuno potrebbe fornirti una richiesta non valida (o legittima ma non comune) che, a causa della progettazione del tuo parser, sovrascrive i dati precedentemente convalidati con un payload che potrebbe causare un cattivo comportamento della tua applicazione.
Quest'ultima forma è meno probabile, ma una funzione di pulizia delle stringhe sql scritta male ampiamente distribuita che ha avuto un problema come questo sarebbe un obiettivo invitante.
Le macchine virtuali Java (e .Net) rilevano il codice che tenta di scrivere al di fuori della memoria riservata. Le applicazioni che non gestiscono correttamente questa operazione possono comunque causare problemi di sicurezza. Se utenti malintenzionati possono attivare eccezioni inserendo input non validi, possono eseguire attacchi denial of service, ad esempio.
Come è già stato sottolineato, Java ha, come linguaggio, il controllo dei limiti su tutti gli accessi alla memoria e, se c'è un errore qui, la colpa è della JVM e non del programma. Tuttavia, quello che dovrebbe essere notato, che è un argomento simile alle perdite di memoria in Java; sebbene non sia possibile distruggere lo stack, un'eccezione ArrayOutOfBoundsException nel posto sbagliato, che non è gestita correttamente, potrebbe comunque finire per rovinare il sistema.
È plausibile che si possa causare un overflow del buffer in un programma Java se si stesse utilizzando la funzione Java Native Interace (JNI) per richiamare il codice esterno e il codice esterno presentava un problema sfruttabile. Questo è abbastanza raro, poiché la maggior parte delle applicazioni evita di utilizzare JNI dove possibile.
È possibile che un metodo scriva in voci valide di un array che non intendeva, tipicamente tramite un intero overflow.
Ad esempio, quanto segue non è sufficiente per controllare i limiti:
/* !! WRONG !! */ 0 <= off && 0 <= len && off+len <= buff.length /* !! WRONG !! */IIRC, StringBufferuna volta aveva un bug del genere, ma non c'era niente di interessante che potessi farci.
0 <= off && 0 <= len && off <= buff.length-lenpenso. Non citarmi. Sembra lo stesso ma non c'è un possibile overflow (nell'originale off + len potrebbe diventare negativo e quindi ovviamente più piccolo della lunghezza dell'array). Assicurati che nessun programmatore di manutenzione lo "riordini" nella forma più ovvia. Trovo l'overflow di interi enormemente confuso. Ci devo pensare per un po ', e poi c'è il fastidioso sospetto che mi sia sbagliato. Ma ovviamente dovrebbe esserci un altro revisore e il programmatore originale - insieme ovviamente non c'è modo che un errore possa passare! (non)
Una delle caratteristiche principali di JAVA è la sicurezza. I programmi scritti in linguaggi interpretati non sono soggetti all'exploit di overflow del buffer, ma puoi sempre causare un overflow del buffer in Interpreter stesso. Anche se sarà difficile. Allo stesso modo Python è anche un linguaggio interpretato ed è al sicuro da overflow del buffer.