JNI Java Native Interface di Java / Dalvik rende Android soggetto a attacchi migliori?

Question

JNI Java Native Interface di Java / Dalvik rende Android soggetto a attacchi migliori?

#1 da (1 voti)
#2 da (1 voti)
#3 da (1 voti)

3

Java ha una funzionalità chiamata Java Native Interface (JNI) , che consente di chiamare nativo funzione codice macchina dall'interno del bytecode di Java. Questa funzione consente di eseguire efficacemente il codice nativo della macchina da una libreria condivisa nativa, che, nel caso di app Android apk, lo sviluppatore dell'app fornisce all'interno del pacchetto apk.

Il mio dubbio è se questo JNI dovrebbe essere un problema di sicurezza ? Cioè quel codice al di fuori della macchina virtuale Dalvik, il codice nativo diretto potrebbe essere un rischio più elevato per attaccare il sistema, dal momento che il bytecode java attraverso Dalvik?

Il codice nativo è un problema di sicurezza più grande del codice in una macchina virtuale?

Alcuni sfondi

JNI non è l'unico modo per eseguire codice nativo, anche se conveniente perché non si deve eseguire molta copia / incorporamento di un binario da eseguire (cioè dalle risorse di apk a una posizione eseguibile) Comunque anche questo è possibile:

 Runtime.getRuntime().exec("/data/data/my.package/my.code.bin").

Ora sono consapevole che, alla fine, nulla è ancora perso, solo perché il codice nativo viene eseguito, ad es. il modello di sicurezza di molti desktop box funziona anche con applicazioni native in esecuzione. In effetti uno è almeno fortunato che Android inserisce le app nel proprio ID utente ID, quindi si potrebbe dire in prima persona che anche in natività uno è più sicuro su Android, che eseguire firefox e chromium con lo stesso me@mybox utente su alcune desktop box .

Il punto di svolta, che motiva anche la domanda se costituisce un problema di sicurezza, è che il codice nativo mi sembra molto più flessibile per attaccare il sistema tramite systemcall e buffer overrun ecc., che possibile per un attacco occorso dall'apk / apps Base codici Java. Dopotutto anche per cose legittime Dalvik / Java si intromette e viene disabilitato a causa del suo obiettivo di portabilità.

Supponendo che vi sia un rischio associato a JNI e alla chiamata exec, sto sbagliando o Android non dispone di un'impostazione di autorizzazione per quello. Quindi, per valutare la domanda, dovrebbero esserci "extra upvotes" per confermare o rifiutare che Android non abbia le impostazioni di autorizzazione per-per-app per JNI. La mia app per iPod installa almeno con il messaggio:

Do you want to install this application? It does not require any special access?

che sembra indicarmi che non richiederebbe alcun permesso. Eppure so che può eseguire codice nativo e codice nativo JNI.

permissions android sandbox

posta humanityANDpeace 10.03.2016 - 14:44

fonte

3 risposte

Leggi altre domande sui tag permissions android sandbox

CSR con solo chiave pubblica con openssl E 'conforme PCI per annotare le informazioni della carta di credito su carta e conservarlo in scatole non presidiate?

score 1 · Answer 1

if this JNI should this be a security concern?

Ciò che è o non è una "preoccupazione" è una dichiarazione di opinione, per la quale la famiglia di siti Overflow dello stack non è adatta.

Is native code a bigger security concern than code in a virtual machine?

Lo descriverei come diverso . Alcuni attacchi sarebbero più facili da codice nativo, come quelli che hai delineato nella tua domanda. Altri attacchi sarebbero più difficili, in quanto il codice nativo non ha API per ottenere un sacco di cose in Android a cui è possibile accedere più facilmente dal codice Java. Se uno è "più grande" è, ancora una volta, una dichiarazione di opinione.

confirming or refuting that Android does not have as-per-app permission settings for JNI

Una corretta. All'utente non viene richiesto se l'app contiene codice nativo di qualsiasi modulo. Questo non è esattamente ciò per cui è il sistema di autorizzazione. Al di là di questo, non è chiaro per me cosa diresti all'utente di JNI in un prompt di autorizzazione ("Questa app esegue tecniche mumbo-jumbo diverse rispetto alle normali app Android. Permetti? Nega?").

score 1 · Answer 2

Qualsiasi app esegue il codice nativo alla fine. Questo è vero per Android con la sua JVM (sia Dalvik o ART), sia per iOS, e per Windows, e persino per SmallTalk. Il codice nativo ha un "vettore di attacco" leggermente diverso rispetto al codice gestito: alcuni tipi di vulnerabilità, ad es. buffer overflow, appartiene a nativo, non a Java. E gli exploit dannosi possono trovare e abusare di tali vulnerabilità.

Ma su Android, il codice nativo, e in particolare quello che di solito intendiamo per codice JNI - i pezzi di software cresciuto in casa o di terze parti, scritto in C ++ o qualche altra lingua non gestita - questo codice viene eseguito nella stessa app sandbox, soggetto alle stesse restrizioni di sicurezza del codice Java. Su Andorid, il tuo codice nativo non può scrivere sulla scheda SD senza esplicito permesso manifest: non perché l'API sia contrassegnata come "vietata" (allusione alla sicurezza dell'App Store controllando quali API l'app utilizza), ma poiché il sistema proibisce in modo proattivo tale accesso, assegnando le autorizzazioni appropriate per ogni processo.

Dovremmo preoccuparci molto di più del codice di sistema che viene eseguito nei processi "elevati", in cui un exploit può acquisire l'accesso di root e caricare l'intero dispositivo (allusione alla vulnerabilità di stagefront recente, che dirotta il servizio multimediale).

Sono d'accordo con la risposta precedente sul fatto che non sarebbe opportuno porre domande medie agli utenti finali che non hanno senso per loro, specialmente quando si tratta di domande relative alla sicurezza.

Sono d'accordo con te sul fatto che scrivere codice non gestito è difficile, e tutti i tipi di errori umani possono rendere il codice JNI meno robusto del codice Java. Bene, questo dovrebbe essere principalmente la preoccupazione dello sviluppatore. L'impatto negativo di tali errori sul prestigio dello sviluppatore è molto più alto di un potenziale danno alla sicurezza per l'utente finale.

La linea di fondo è stata ripetuta da Google ancora e ancora: C ++ non è Mt.Everest. Non andare in C ++ solo perché è lì. Sopporta i rischi e guadagna con attenzione, e probabilmente scoprirai che sarai meglio servito da Java puro.

score 1 · Answer 3

Sì, assolutamente.
In realtà questa risposta è piuttosto banale, in quanto nativo sarebbe ovviamente vulnerabile a ulteriori classi di attacco, come l'overflow del buffer - proprio come si nota nella domanda.

C'è un CWE molto specifico (111) che si applica qui :

When a Java application uses the Java Native Interface (JNI) to call code written in another programming language, it can expose the application to weaknesses in that code, even if those weaknesses cannot occur in Java.

Ora, la cosa interessante qui è in realtà la sandbox Android.
Mentre le vulnerabilità menzionate sono di fatto rilevanti qui, e rendono il codice nativo più a rischio, che non necessariamente abilita una libreria ad uscire e ad uscire dalla sandbox dei privilegi. Come dici tu, le app Android vengono eseguite con il proprio UID e privilegi limitati, per processo.
In realtà trovo questo altamente improbabile, anche se non impossibile - se lo trovi, sarebbe una bella rivelazione, e spero che venga risolto in breve tempo.