Come può il buffer overflow essere dannoso in Android?

Prendiamo ad esempio Stagefright, la libreria multimediale scritta in C ++

In che modo i bypass superano i privilegi assegnati è semplice; Il codice C può scrivere direttamente in memoria. Il tuo compito come sviluppatore è quello di assicurarti che cosa inserirai, altrimenti scriverà allegramente altre istruzioni con lo stesso privilegio. Stagefright ha molti privilegi. E le informazioni che escono dal buffer potrebbero essere un video casuale di un gatto da Internet (che quindi -grande- i privilegi della libreria multimediale)

Quindi sarebbe ingenuo presumere che gli overflow non siano dannosi. Stagefright conteneva buffer overflow e questo è estremamente pericoloso. Gli sviluppatori di Android hanno reso più difficile lo sfruttamento implementando (tra le altre misure) la randomizzazione del layout dello spazio degli indirizzi (ASLR), questo rende gli offset utilizzabili, causando un errore piuttosto che l'esecuzione del codice. Ma combinando questo con le vulnerabilità del browser, le informazioni possono essere trapelate sulla posizione corrente delle pagine di memoria, quindi l'esecuzione del codice è ancora possibile.

Consiglierei di leggere su Metaphor, un'implementazione Stagefright che include il bypass ASLR, il documento cartaceo e il codice PoC sono disponibili online

Lasciatemi parafrasare la domanda dell'op: Android ha un modello di isolamento dell'app basato sull'ID utente e in che modo potrebbe bypassarlo?

La risposta è che tu trabocchi delle parti che sono condivise tra le app: servizi, app di sistema e il kernel di Linux stesso. Molti di questi componenti sono scritti in C / C ++, quindi sono vulnerabili.

Questo è in effetti il modo in cui esegui l'escalation dei privilegi in tutti i sistemi multiutente e Android non è niente di speciale.

I thought that even if the overflow happens, shellcode written to app's mem page will only have the same privileges as the app itself?

A meno che l'overflow sia nel kernel o in qualcosa di esposto sulla comunicazione tra processi (Android fornisce molte cose come servizi), sì.

Tuttavia, si noti che le tre applicazioni chiave: messaggistica, e-mail e browser, hanno molti privilegi. Basta rubare alcuni importanti dati privati. Queste applicazioni sono anche quelle che interpretano contenuti esterni inaffidabili. Spetta quindi a queste applicazioni assicurarsi che il contenuto esterno (come le pagine web) non possa utilizzare le autorizzazioni che non dovrebbe.

Queste applicazioni eseguono anche molti codici C o C ++ potenzialmente vulnerabili, dal momento che interpretare parte del contenuto (in particolare video e javascript) è CPU e memoria intensiva al punto Java e JVM (la JVM Android è inferiore al desktop uno) non sono all'altezza del compito, e anche prima che il codice venga riutilizzato da altre piattaforme. Sono le vulnerabilità in questo codice che la maggior parte degli obiettivi di exploit gravi.

Non sono un esperto di sicurezza Android, ma penso di poter rispondere alla domanda, diciamo per uno scenario Apache / Linux e penso che esistano anche minacce equivalenti per Android (lasciamo da parte la domanda per il momento se sono possibili overflow del buffer in Android o no).

1. Un buffer overflow consente a un utente malintenzionato di inserire il codice nella memoria di un processo in esecuzione. Di solito, l'utente malintenzionato proverà a iniettare codice che avvia una shell (/ bin / bash, ad esempio) che invia il suo stdout alla sua casella di attacco remoto e riceve lo stdin da quella casella. Il risultato è una finestra di terminale sul computer dell'attaccante, ma il processo della shell viene eseguito sulla casella attaccata. Ora, come dici tu in Android, il processo viene eseguito nello spazio utente. La stessa cosa è vera per un normale scenario di server Web su Linux. Cioè si inserisce il codice in una memoria di processo il cui proprietario non ha molti privilegi (www-data o apache non sono affatto potenti su Linux). A questo punto nel tempo è possibile eseguire solo azioni da remoto dal box dell'utente che l'utente è autorizzato a fare nel sistema operativo. In Linux, questo è piuttosto limitato e come dici tu anche in Android.
2. Il prossimo passo verso cui punta l'attaccante è un'escalation di privilegi. Cioè trova un altro difetto nel sistema operativo / qualsiasi cosa ti permetta di uscire dal tipo di "sandbox" in cui ti trovi. Ci sono centinaia / migliaia di bug in Windows / Linux / qualsiasi cosa che permetta l'escalation dei privilegi da un utente limitato a root / amministratore (contato negli ultimi 15 anni). Per Android questo significa che dovresti trovare un tale bug nel sistema operativo Android che ti permetta di uscire dallo spazio utente. Poiché la perfezione non esiste in questo mondo ci sono probabilmente bug che permettono di farlo. Dipende solo dal tuo tempo e dalla tua energia, che tu li trovi o meno.
3. Può esistere buffer overflow in Android? Certo, possono. Android è scritto in C come la maggior parte dei sistemi operativi. Ogni venditore di telefoni porta il proprio gusto del sistema operativo, quindi cosa ti rende certo che non uno Samsung / LG / qualsiasi sviluppatore introduca un difetto nel codice? Sull'interfaccia tra Java e C la parte C deve ancora fare il controllo dei limiti, altrimenti si sovrascrive ancora la memoria. Tuttavia, come sviluppatore di app non devi più preoccuparti di questo problema perché scrivere in Java direttamente su indirizzi di memoria non è possibile.

Diciamo che hai iniettato il tuo codice in un processo. Ora puoi:

• Pasticcia con i dati e le autorizzazioni accessibili al processo (ruba i dettagli dell'account dell'app, accedi alle tue foto se l'app ha i permessi, pubblica un messaggio twitter nel tuo nome se l'app attaccata era twitter, ...)
• Utilizza un attacco di escalation di privilegi per ottenere privilegi più elevati
• A volte parti dell'app (in particolare le librerie multimediali) funzionano con privilegi più elevati. Se attacchi quelli, puoi ottenere privilegi più alti. Stagefright usava questo se non ricordo male.
• Attacca un'altra app / processo sul telefono (anche quelli non accessibili da remoto) e ripeti l'intera operazione fino a raggiungere il tuo target

Quindi anche se (inizialmente) puoi accedere solo al tuo spazio di indirizzo, hai molte possibilità.

Per chiarimenti: il processo dell'app è in esecuzione con l'ID utente. Il processo potrebbe essere la VM Dalvik. Potrebbe anche essere un codice nativo utilizzando l'NDK di Android scritto in C / C ++. Questo è spesso usato da librerie multimediali, giochi e funzionalità del SO di basso livello.

In generale solo le vulnerabilità critiche del bufferoverflow sono discusse nei media, queste sono solo una piccola parte di tutte le vulnerabilità.