Aggiornamenti sulla sicurezza e risorse

Il team di sicurezza Android è responsabile della gestione delle vulnerabilità di sicurezza scoperte nella piattaforma Android e in molte delle principali app Android in bundle con i dispositivi Android.

Il team di sicurezza di Android rileva le vulnerabilità di sicurezza tramite ricerche interne e risponde anche ai bug segnalati da terze parti. Le fonti di bug esterni includono problemi segnalati tramite il modello Problema di sicurezza Android , ricerche accademiche pubblicate e prepubblicate, responsabili di progetti open source a monte, notifiche dei nostri partner produttori di dispositivi e problemi divulgati pubblicamente pubblicati su blog o social media.

Segnalazione di problemi di sicurezza

Qualsiasi sviluppatore, utente Android o ricercatore di sicurezza può notificare al team di sicurezza Android potenziali problemi di sicurezza tramite il modulo di segnalazione delle vulnerabilità di sicurezza .

I bug contrassegnati come problemi di sicurezza non sono visibili esternamente, ma alla fine possono essere resi visibili dopo che il problema è stato valutato o risolto. Se prevedi di inviare una patch o un test CTS (Compatibility Test Suite) per risolvere un problema di sicurezza, allegalo alla segnalazione di bug e attendi una risposta prima di caricare il codice su AOSP.

Triaging bug

La prima attività nella gestione di una vulnerabilità di sicurezza è identificare la gravità del bug e quale componente di Android è interessato. La gravità determina la priorità del problema e il componente determina chi corregge il bug, chi riceve la notifica e come la correzione viene distribuita agli utenti.

Tipi di processo

Questa tabella copre le definizioni dei tipi di processo. Il tipo di processo può essere definito dal tipo di app o processo o dall'area in cui viene eseguito. Questa tabella è ordinata dal meno al più privilegiato.

Tipo di processo	Definizione del tipo
Processo vincolato	Un processo che viene eseguito in un dominio SELinux altamente limitato. O Un processo molto più limitato di una normale app.
Processo senza privilegi	Un'applicazione o un processo eseguito in un dominio SELinux con l'attributo `untrusted_app_all` o con restrizioni equivalenti.
Processo privilegiato	Un'app o un processo con funzionalità che sarebbero vietate dal dominio SELinux `untrusted_app` . O Un'app o un processo con privilegi importanti che un'app di terze parti non può ottenere. O Un componente hardware integrato nel dispositivo che non fa parte della Trusted Computing Base (TCB).
Base informatica affidabile (TCB)	La funzionalità che fa parte del kernel, viene eseguita nello stesso contesto della CPU del kernel (come i driver di dispositivo), ha accesso diretto alla memoria del kernel (come i componenti hardware sul dispositivo), ha la capacità di caricare gli script in un componente del kernel ( per esempio, eBPF), il Baseband Processor, o è uno dei pochi servizi utente considerati equivalenti al kernel: `apexd` , `bpfloader` , `init` , `ueventd` e `vold` .
Boot loader	Un componente che configura il dispositivo all'avvio e quindi passa il controllo al sistema operativo Android.
Trusted Execution Environment (TEE)	Un componente progettato per essere protetto anche da un kernel ostile (ad esempio, TrustZone e Hypervisor).
Elemento sicuro (SE)	Un componente opzionale progettato per essere protetto da tutti gli altri componenti sul dispositivo e da attacchi fisici, come definito nell'introduzione a Secure Elements .

Gravità

La gravità di un bug generalmente riflette il potenziale danno che potrebbe verificarsi se un bug fosse sfruttato con successo. Utilizzare i seguenti criteri per determinare la gravità.

Valutazione	Conseguenza del successo dello sfruttamento
Critico	Accesso non autorizzato ai dati protetto dalla SE Esecuzione di codice arbitrario nel TEE o SE Esecuzione di codice arbitrario remoto in un processo privilegiato, bootloader o TCB Denial of Service permanente remoto (inoperabilità del dispositivo: completamente permanente o che richiede il reflash dell'intero sistema operativo o un ripristino delle impostazioni di fabbrica) Bypass remoto dei requisiti di interazione dell'utente sull'installazione del pacchetto o comportamento equivalente Bypass remoto dei requisiti di interazione dell'utente per qualsiasi sviluppatore, impostazioni di sicurezza o privacy Bypass di avvio sicuro remoto Bypass di meccanismi di sicurezza progettati per prevenire il malfunzionamento di componenti hardware critici (ad esempio, protezioni termiche)
Alto	Bypass di avvio sicuro locale Un bypass completo di una funzionalità di sicurezza di base (come SELinux, FDE o seccomp) Esecuzione di codice arbitrario remoto in un processo senza privilegi Esecuzione di codice arbitrario locale in un processo privilegiato, bootloader o TCB Accesso non autorizzato ai dati protetto dal TEE Attacchi contro un SE che si traducono in un downgrade a un'implementazione meno sicura Bypass locale dei requisiti di interazione dell'utente sull'installazione del pacchetto o comportamento equivalente Accesso remoto ai dati protetti (dati limitati a un processo privilegiato) Denial of Service permanente locale (inoperabilità del dispositivo: permanente o che richiede il reflash dell'intero sistema operativo o il ripristino delle impostazioni di fabbrica) Esclusione remota dei requisiti di interazione dell'utente (accesso a funzionalità o dati che normalmente richiederebbero l'avvio o l'autorizzazione dell'utente) Trasmissione di informazioni sensibili su un protocollo di rete non sicuro (ad esempio, HTTP e Bluetooth non crittografato) quando il richiedente si aspetta una trasmissione sicura (si noti che questo non si applica alla crittografia Wi-Fi, come WEP) Un bypass generale per una difesa approfondita o una tecnologia di mitigazione degli exploit nel bootloader, TEE o SE Un bypass generale per le protezioni del sistema operativo che isolano i dati delle app oi profili utente l'uno dall'altro Bypass locale dei requisiti di interazione dell'utente per qualsiasi sviluppatore, impostazioni di sicurezza o privacy Vulnerabilità crittografica in TLS (Transport Layer Security) standard che consente attacchi sul percorso Bypass lockscreen Esclusione della protezione del dispositivo / protezione del ripristino delle impostazioni di fabbrica / restrizioni dell'operatore Prevenzione mirata dell'accesso ai servizi di emergenza Bypass dei requisiti di interazione dell'utente garantiti dal TEE
Moderare	Esecuzione di codice arbitrario remoto in un processo vincolato Denial of Service del dispositivo temporaneo remoto (blocco o riavvio remoto) Esecuzione di codice arbitrario locale in un processo senza privilegi Un bypass generale per una difesa in profondità o sfruttare la tecnologia di mitigazione in un processo privilegiato o TCB Bypass delle restrizioni su un processo vincolato Accesso remoto ai dati non protetti (dati normalmente accessibili a qualsiasi app installata localmente) Accesso locale ai dati protetti (dati limitati a un processo privilegiato) Esclusione locale dei requisiti di interazione dell'utente (accesso a funzionalità o dati che normalmente richiederebbero l'avvio o l'autorizzazione dell'utente) Vulnerabilità crittografica nelle primitive crittografiche standard che consente la fuoriuscita di testo in chiaro (non primitive utilizzate in TLS) Bypassare la crittografia o l'autenticazione Wi-Fi
Basso	Esecuzione di codice arbitrario locale in un processo vincolato Vulnerabilità crittografica nell'utilizzo non standard Un bypass generale per una difesa approfondita a livello di utente o una tecnologia di mitigazione degli exploit in un processo senza privilegi
Impatto trascurabile sulla sicurezza (NSI)	Una vulnerabilità il cui impatto è stato mitigato da uno o più modificatori di classificazione o modifiche dell'architettura specifiche della versione in modo tale che la gravità effettiva sia inferiore a Bassa, sebbene il problema di codice sottostante possa rimanere Qualsiasi vulnerabilità che richiede un filesystem malformato, se quel filesystem viene sempre adottato / crittografato prima dell'uso.

Modificatori di valutazione

Sebbene la gravità delle vulnerabilità della sicurezza sia spesso facile da identificare, le valutazioni possono cambiare in base alle circostanze.

Motivo	Effetto
Richiede l'esecuzione come processo privilegiato per eseguire l'attacco	-1 Gravità
I dettagli specifici della vulnerabilità limitano l'impatto del problema	-1 Gravità
Bypass dell'autenticazione biometrica che richiede informazioni biometriche direttamente dal proprietario del dispositivo	-1 Gravità
Le configurazioni del compilatore o della piattaforma mitigano una vulnerabilità nel codice sorgente	Gravità moderata se la vulnerabilità sottostante è moderata o superiore
Richiede l'accesso fisico ai componenti interni del dispositivo ed è ancora possibile se il telefono è spento o non è stato sbloccato da quando è stato acceso	-1 Gravità
Richiede l'accesso fisico ai componenti interni del dispositivo mentre il telefono è acceso ed è stato precedentemente sbloccato	-2 Gravità
Un attacco locale che richiede lo sblocco del bootloader	Non superiore a Basso
Un attacco locale che richiede l'attivazione della modalità sviluppatore o di eventuali impostazioni della modalità sviluppatore persistente sul dispositivo (e non è un bug nella modalità sviluppatore stessa).	Non superiore a Basso
Se nessun dominio SELinux può condurre l'operazione in base alla SEPolicy fornita da Google	Impatto trascurabile sulla sicurezza

Locale contro prossimale contro remoto

Un vettore di attacco remoto indica che il bug può essere sfruttato senza installare un'app o senza accesso fisico a un dispositivo. Ciò include bug che possono essere attivati navigando in una pagina Web, leggendo un'e-mail, ricevendo un messaggio SMS o connettendosi a una rete ostile. Ai fini delle nostre valutazioni di gravità, il team di sicurezza di Android considera anche i vettori di attacco "prossimali" come remoti. Questi includono bug che possono essere sfruttati solo da un utente malintenzionato che è fisicamente vicino al dispositivo di destinazione, ad esempio un bug che richiede l'invio di pacchetti Wi-Fi o Bluetooth non validi. Il team di sicurezza di Android considera gli attacchi basati su NFC come prossimali e quindi remoti.

Gli attacchi locali richiedono che la vittima esegua un'app, installando ed eseguendo un'app o acconsentendo a eseguire un'app istantanea . Ai fini delle valutazioni di gravità, il team di sicurezza di Android considera anche i vettori di attacchi fisici come locali. Questi includono bug che possono essere sfruttati solo da un utente malintenzionato che ha accesso fisico al dispositivo, ad esempio un bug in una schermata di blocco o uno che richiede il collegamento di un cavo USB. Si noti che gli attacchi che richiedono una connessione USB hanno la stessa gravità indipendentemente dal fatto che il dispositivo debba essere sbloccato o meno; è normale che i dispositivi vengano sbloccati mentre sono collegati all'USB.

Sicurezza Wi-Fi

Android presume che tutte le reti siano ostili e potrebbero iniettare attacchi o spiare il traffico. Sebbene la sicurezza a livello di collegamento (ad esempio, la crittografia Wi-Fi) protegga la comunicazione tra un dispositivo e il punto di accesso Wi-Fi a cui è connesso, non fa nulla per proteggere i collegamenti rimanenti nella catena tra il dispositivo ei server con cui sta comunicando .

Al contrario, HTTPS in genere protegge l'intera comunicazione end-to-end, crittografando i dati alla fonte, quindi decrittografandoli e verificandoli solo una volta raggiunta la destinazione finale. Per questo motivo, le vulnerabilità che compromettono la sicurezza Wi-Fi sono classificate meno gravi rispetto alle vulnerabilità in HTTPS / TLS: la crittografia Wi-Fi da sola non è sufficiente per la maggior parte delle comunicazioni su Internet.

Autenticazione biometrica

L'autenticazione biometrica è uno spazio impegnativo e anche i migliori sistemi possono essere ingannati da una quasi corrispondenza (vedi Blog degli sviluppatori Android: Lockscreen e miglioramenti dell'autenticazione in Android 11 ). Questi livelli di gravità distinguono due classi di attacchi e hanno lo scopo di riflettere il rischio effettivo per l'utente finale.

La prima classe di attacchi consente di aggirare l'autenticazione biometrica in modo generalizzabile, senza dati biometrici di alta qualità da parte del proprietario. Se, ad esempio, un utente malintenzionato può posizionare un pezzo di gomma su un sensore di impronte digitali e questo consente l'accesso al dispositivo in base ai residui lasciati sul sensore, si tratta di un semplice attacco che potrebbe essere eseguito su qualsiasi dispositivo suscettibile. Non richiede alcuna conoscenza del proprietario del dispositivo. Dato che è generalizzabile e ha un potenziale impatto su un numero maggiore di utenti, questo attacco riceve il livello di gravità completo (ad esempio, Alto, per un bypass di Lockscreen).

L'altra classe di attacchi generalmente coinvolge uno strumento di attacco di presentazione (spoof) basato sul proprietario del dispositivo. A volte queste informazioni biometriche sono relativamente facili da ottenere (ad esempio, se l'immagine del profilo di qualcuno sui social media è sufficiente per ingannare l'autenticazione biometrica, un bypass biometrico riceverebbe il livello di gravità completo). Ma se un utente malintenzionato dovesse acquisire dati biometrici direttamente dal proprietario del dispositivo (ad esempio, una scansione a infrarossi del proprio viso), questa è una barriera abbastanza significativa da limitare il numero di persone colpite dall'attacco, quindi c'è un modificatore -1 .

Componente interessato

Il team di sviluppo responsabile della correzione del bug dipende dal componente in cui si trova il bug. Potrebbe essere un componente principale della piattaforma Android, un driver del kernel fornito da un produttore di apparecchiature originali (OEM) o una delle app precaricate sui dispositivi Pixel .

I bug nel codice AOSP vengono corretti dal team di ingegneri di Android. Bug di bassa gravità, bug in alcuni componenti o bug già noti pubblicamente possono essere corretti direttamente nel ramo principale AOSP pubblicamente disponibile; altrimenti vengono risolti prima nei nostri repository interni.

Il componente è anche un fattore nel modo in cui gli utenti ottengono gli aggiornamenti. Un bug nel framework o nel kernel richiede un aggiornamento del firmware over-the-air (OTA) che ogni OEM deve eseguire. Un bug in un'app o una libreria pubblicata su Google Play (ad esempio, Gmail, Google Play Services o WebView) può essere inviato agli utenti Android come aggiornamento da Google Play.

Notifica ai partner

Quando una vulnerabilità di sicurezza in AOSP viene risolta in un bollettino sulla sicurezza Android, informeremo i partner Android dei dettagli del problema e forniremo le patch. L'elenco delle versioni supportate da backport cambia con ogni nuova versione di Android. Contatta il produttore del dispositivo per l'elenco dei dispositivi supportati.

Rilascio del codice su AOSP

Se il bug di sicurezza si trova in un componente AOSP, la correzione viene inviata ad AOSP dopo che l'OTA è stato rilasciato agli utenti. Le correzioni per i problemi di bassa gravità possono essere inviate direttamente al ramo principale AOSP prima che una correzione sia disponibile per i dispositivi tramite un'OTA.

Ricezione di aggiornamenti Android

Gli aggiornamenti al sistema Android vengono generalmente forniti ai dispositivi tramite pacchetti di aggiornamento OTA. Questi aggiornamenti possono provenire dall'OEM che ha prodotto il dispositivo o dal gestore che fornisce il servizio al dispositivo. Gli aggiornamenti del dispositivo Google Pixel provengono dal team di Google Pixel dopo aver superato una procedura di test di accettazione tecnica (TA) dell'operatore. Google pubblica anche immagini di fabbrica Pixel che possono essere caricate lateralmente sui dispositivi.

Aggiornamento dei servizi di Google

Oltre a fornire patch per i bug di sicurezza, il team di sicurezza Android esamina i bug di sicurezza per determinare se ci sono altri modi per proteggere gli utenti. Ad esempio, Google Play esegue la scansione di tutte le app e rimuove qualsiasi app che tenti di sfruttare un bug di sicurezza. Per le app installate dall'esterno di Google Play, i dispositivi con Google Play Services possono anche utilizzare la funzione Verifica app per avvisare gli utenti delle app che potrebbero essere potenzialmente dannose.

Altre risorse

Informazioni per gli sviluppatori di app Android: https://developer.android.com

Le informazioni sulla sicurezza sono disponibili in tutti i siti Android Open Source e Developer. Buoni posti per iniziare:

Rapporti

A volte il team di sicurezza Android pubblica rapporti o white paper. Vedere Rapporti sulla sicurezza per maggiori dettagli.