Java ha buffer overflow?

Question

Java ha buffer overflow? Se sì, puoi darmi degli scenari?

Answer 1

Poiché le stringhe Java sono basate su array di caratteri e Java controlla automaticamente i limiti dell'array, gli overflow del buffer sono possibili solo in scenari insoliti:

1. Se chiami il codice nativo tramite JNI
2. Nella stessa JVM (di solito scritta in C ++)
3. L'interprete o il compilatore JIT non funzionano correttamente (controlli dei limiti obbligatori del bytecode Java)

Answer 2

I linguaggi gestiti come Java e C # non presentano questi problemi, ma le macchine virtuali specifiche (JVM / CLR / ecc.) che effettivamente eseguono il codice potrebbero.

Answer 3

A tutti gli effetti, no.

Java ha un array controllo dei limiti che controllerà che non è possibile accedere ai dati dall'area esterna matrice allocata. Quando si tenta di accedere ad un'area oltre la dimensione dell'array, un ArrayOutOfBounds verrà generata un'eccezione.

Se si verifica un sovraccarico del buffer, probabilmente deriva da 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 macchina virtuale Java.

Answer 4

Un overflow del buffer nel senso stretto della sovrascrittura dello stack o dello stesso heap richiederebbe:

1. Un bug nel framework (questi sono esistiti in passato e potrebbero benissimo)
2. L'uso di JNI (essenzialmente non utilizza più il codice gestito)

Un buffer overflow, nel senso che si dispone di codice che utilizza un buffer e il codice è responsabile dell'analisi corretta ma non è possibile 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 certo payload che causerebbe un cattivo funzionamento dell'applicazione.

Quest'ultima forma è meno probabile, ma una funzione di pulizia della stringa sql scritta in modo errato ampiamente distribuita che ha avuto un problema come questo sarebbe un obiettivo invitante.

Answer 5

Sì e no. No, nel senso che non puoi davvero crearti per errore aprendoti a una vulnerabilità di buffer overflow perché è un modello di memoria gestita. Tuttavia, possono esserci vulnerabilità di overflow del buffer in JVM e JDK. Vedi questo avviso Secunia:

http://secunia.com/advisories/25295

O vedi questi vecchi avvisi su diverse vulnerabilità JDK e JRE precedenti:

• Vulnerabilità di overflow di buffer e numeri interi in Java Runtime Environment (JRE) " unpack200 " L'utilità di decompressione JAR può portare all'escalation dei privilegi https://download.oracle.com/sunalerts/1020225.1 .html

    

  Vulnerabilità di integer e buffer overflow in Java Runtime   Ambiente (JRE) con applet di decompressione e Java Web Start   applicazioni che usano il " unpack200 " L'utilità di decompressione JAR può consentire un   applet o applicazione non attendibili per l'escalation dei privilegi. Per esempio,   un'applet non attendibile può concedersi le autorizzazioni per leggere e scrivere   file locali o eseguire applicazioni locali accessibili al   utente che esegue l'applet non attendibile.

       

  Sun riconosce con ringraziamenti, " regenrecht " lavorare con iDefense   VCP ( http://labs.idefense.com/vcp/ ) e Chris Evans di Google per   portando questi problemi alla nostra attenzione.

• Sono state identificate più vulnerabilità in Sun Java Development Kit (JDK) e Java Runtime Environment (JRE). https://security.gentoo.org/glsa/200705-23

    

  Una vulnerabilità non specificata che comporta un " uso errato del sistema   & Classi quot; è stato segnalato dal team di sicurezza di Fujitsu. Inoltre,   Chris Evans del team di sicurezza di Google ha segnalato un overflow di numeri interi   con conseguente overflow del buffer nel parser ICC utilizzato con JPG o BMP   file e una chiamata open () non corretta a / dev / tty durante l'elaborazione   alcuni file BMP.

Answer 6

Le macchine virtuali Java (e .Net) rilevano il codice che tenta di scrivere al di fuori della memoria riservata. Le applicazioni che non lo gestiscono correttamente possono comunque causare problemi di sicurezza. Se gli utenti malintenzionati possono attivare eccezioni immettendo input non validi, ad esempio possono eseguire attacchi di negazione del servizio.

Answer 7

Come è già stato sottolineato, Java ha, come lingua, limiti di controllo su tutto l'accesso alla memoria, e se c'è un errore qui, la JVM è in errore e non il programma. Tuttavia, ciò che dovrebbe essere notato, che è un argomento simile alle perdite di memoria in Java; sebbene non sia possibile distruggere lo stack, un ArrayOutOfBoundsException nel posto sbagliato, che non viene gestito correttamente, potrebbe comunque finire per rovinare il sistema.

Answer 8

È possibile per un metodo scrivere in voci valide di un array che non intendeva, in genere tramite overflow di numeri interi.

Ad esempio, quanto segue non è sufficiente per controllare i limiti:

/* !! WRONG !! */ 0 <= off && 0 <= len && off+len <= buff.length /* !! WRONG !! */

IIRC, StringBuffer una volta aveva un bug del genere, ma non c'era niente di interessante che tu potessi fare con esso.

Answer 9

Si potrebbe presumibilmente causare un overflow del buffer in un programma Java se si stesse utilizzando la funzione Java Native Interace (JNI) per invocare il codice esterno e il codice esterno avesse un problema sfruttabile. Questo è abbastanza raro, poiché la maggior parte delle applicazioni evita di usare JNI ove possibile.

Answer 10

Una delle caratteristiche chiave di JAVA è la sicurezza. I programmi scritti in lingue interpretate non sono inclini all'exploit di overflow del buffer, ma è sempre possibile causare un overflow del buffer nell'interprete stesso. Anche se sarà difficile. Allo stesso modo Python è anche un linguaggio interpretato ed è al sicuro da buffer overflow.