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 trova le vulnerabilità della sicurezza attraverso la ricerca interna e risponde anche ai bug segnalati da terze parti. Le fonti di bug esterni includono problemi segnalati tramite il modulo di vulnerabilità , ricerche accademiche pubblicate e prepubblicate, manutentori di progetti open source a monte, notifiche dai 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 di Android potenziali problemi di sicurezza tramite il modulo di vulnerabilità .
I bug contrassegnati come problemi di sicurezza non sono visibili esternamente, ma possono eventualmente essere resi visibili dopo che il problema è stato valutato o risolto. Se prevedi di inviare una patch o un test Compatibility Test Suite (CTS) per risolvere un problema di sicurezza, allegalo alla segnalazione del bug e attendi una risposta prima di caricare il codice su AOSP.
Triage dei bug
Il primo compito 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 contesto
Questa tabella copre le definizioni dei contesti di sicurezza hardware e software. Il contesto può essere definito dalla sensibilità dei dati che in genere elabora o dall'area in cui viene eseguito. Non tutti i contesti di sicurezza sono applicabili a tutti i sistemi. Questa tabella è ordinata dal meno privilegiato al più privilegiato.
Tipo di contesto | Definizione del tipo |
---|---|
Contesto vincolato | Un ambiente di esecuzione limitato in cui vengono fornite solo le autorizzazioni minime. Ad esempio, applicazioni attendibili che elaborano dati non attendibili all'interno di un ambiente sandbox. |
Contesto non privilegiato | Un tipico ambiente di esecuzione previsto dal codice senza privilegi. Ad esempio, un'applicazione Android eseguita in un dominio SELinux con l'attributo untrusted_app_all . |
Contesto privilegiato | Un ambiente di esecuzione privilegiato che può avere accesso ad autorizzazioni elevate, gestisce PII di più utenti e/o mantiene l'integrità del sistema. Ad esempio, un'applicazione Android con funzionalità che sarebbero vietate dal dominio untrusted_app di SELinux o con accesso alle autorizzazioni privileged|signature . |
Kernel del sistema operativo | Funzionalità che:
|
Base hardware attendibile (THB) | Componenti hardware discreti, generalmente sul SoC, che forniscono funzionalità critiche per i casi d'uso principali del dispositivo (come bande di base cellulari, DSP, GPU e processori ML). |
Catena di bootloader | Un componente che configura il dispositivo all'avvio e quindi passa il controllo al sistema operativo Android. |
Ambiente di esecuzione attendibile (TEE) | Un componente progettato per essere protetto anche da un kernel del sistema operativo ostile (ad esempio, TrustZone e hypervisor, come pKVM, che proteggono le macchine virtuali dal kernel del sistema operativo). |
Enclave sicura / Elemento sicuro (SE) | Un componente hardware facoltativo progettato per essere protetto da tutti gli altri componenti del dispositivo e da attacchi fisici, come definito in Introduzione a Secure Elements . Ciò include il chip Titan-M presente in alcuni dispositivi Android. |
Gravità
La gravità di un bug generalmente riflette il potenziale danno che potrebbe verificarsi se un bug venisse sfruttato con successo. Utilizzare i seguenti criteri per determinare la gravità.
Valutazione | Conseguenza di uno sfruttamento riuscito |
---|---|
Critico |
|
Alto |
|
Moderare |
|
Basso |
|
Impatto sulla sicurezza trascurabile (NSI) |
|
Modificatori di valutazione
Sebbene la gravità delle vulnerabilità della sicurezza sia spesso facile da identificare, le classificazioni possono cambiare in base alle circostanze.
Motivo | Effetto |
---|---|
Richiede l'esecuzione come contesto privilegiato per eseguire l'attacco (non applicabile a TEE, SE e hypervisor come pKVM) | -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 alle parti interne del dispositivo ed è ancora possibile se il dispositivo è spento o non è stato sbloccato dall'accensione | -1 Gravità |
Richiede l'accesso fisico alle parti interne del dispositivo mentre il dispositivo è acceso ed è stato precedentemente sbloccato | -2 Gravità |
Un attacco locale che richiede lo sblocco della catena del bootloader | Non superiore a Basso |
Un attacco locale che richiede che la modalità sviluppatore o qualsiasi impostazione persistente della modalità sviluppatore sia attualmente abilitata sul dispositivo (e non è un bug nella stessa modalità sviluppatore). | Non superiore a Basso |
Se nessun dominio SELinux può eseguire l'operazione in base alla SEPolicy fornita da Google | Impatto sulla sicurezza trascurabile |
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à, consideriamo anche i vettori di attacco "prossimali" come remoti. Questi includono bug che possono essere sfruttati solo da un utente malintenzionato che si trova fisicamente vicino al dispositivo di destinazione, ad esempio un bug che richiede l'invio di pacchetti Wi-Fi o Bluetooth non validi. Consideriamo gli attacchi a banda ultralarga (UWB) e 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 all'esecuzione di un'app istantanea . I dispositivi associati accoppiati saranno considerati locali. Ai fini delle valutazioni di gravità, il team di sicurezza di Android considera anche i vettori di attacco fisico 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.
Sicurezza della rete
Android presuppone che tutte le reti siano ostili e potrebbero iniettare attacchi o spiare il traffico. Mentre la sicurezza a livello di collegamento (ad esempio, la crittografia Wi-Fi) protegge la comunicazione tra un dispositivo e il punto di accesso a cui è connesso, non fa nulla per proteggere i collegamenti rimanenti nella catena tra il dispositivo e i 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 della rete a livello di collegamento sono classificate come meno gravi delle 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 (vedere Blog degli sviluppatori Android: Lockscreen e miglioramenti dell'autenticazione in Android 11 ). Questi livelli di gravità distinguono tra 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à dal proprietario. Se, ad esempio, un utente malintenzionato può posizionare un pezzo di gomma su un sensore di impronte digitali e concede l'accesso al dispositivo in base ai residui lasciati sul sensore, si tratta di un semplice attacco che potrebbe essere eseguito su qualsiasi dispositivo sensibile. Non richiede alcuna conoscenza del proprietario del dispositivo. Dato che è generalizzabile e potenzialmente ha un impatto su un numero maggiore di utenti, questo attacco riceve il livello di gravità completo (ad esempio, Alto, per un bypass della schermata di blocco).
L'altra classe di attacchi prevede generalmente 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, allora un bypass biometrico riceverebbe il punteggio 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 .
SYSTEM_ALERT_WINDOW
e Tapjacking
Per informazioni sulle nostre politiche relative a SYSTEM_ALERT_WINDOW
e al tapjacking, consulta la sezione " Tapjacking/overlay SYSTEM_ALERT_WINDOW vulnerability on a non-security-critical screen " della pagina Bugs with no security impact della BugHunter University.
Sicurezza multiutente nel sistema operativo Android Automotive
Il sistema operativo Android Automotive adotta un modello di sicurezza multiutente diverso dagli altri fattori di forma. Ogni utente Android è destinato a essere utilizzato da una persona fisica diversa. Ad esempio, un utente ospite temporaneo può essere assegnato a un amico che prende in prestito il veicolo dal proprietario dell'auto. Per soddisfare casi d'uso come questo, gli utenti hanno accesso per impostazione predefinita ai componenti necessari per utilizzare il veicolo, come le impostazioni Wi-Fi e della rete cellulare.
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 determinati componenti o bug già noti pubblicamente possono essere corretti direttamente nel ramo master AOSP disponibile al pubblico; altrimenti vengono corretti 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 inviare. Un bug in un'app o in una raccolta pubblicata su Google Play (ad esempio, Gmail, Google Play Services o WebView) può essere inviato agli utenti Android come aggiornamento da Google Play.
Avvisare i partner
Quando una vulnerabilità di sicurezza in AOSP viene risolta in un bollettino sulla sicurezza di Android, notificheremo ai partner Android i dettagli del problema e forniremo le patch. L'elenco delle versioni supportate dal backport cambia con ogni nuova versione di Android. Contatta il produttore del dispositivo per l'elenco dei dispositivi supportati.
Rilascio del codice ad 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 problemi di bassa gravità possono essere inviate direttamente al ramo principale AOSP prima che una correzione sia disponibile per i dispositivi tramite un OTA.
Ricevere aggiornamenti Android
Gli aggiornamenti del 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 corriere 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 Pixel Factory che possono essere caricate lateralmente sui dispositivi.
Aggiornamento dei servizi Google
Oltre a fornire patch per i bug di sicurezza, il team di sicurezza di Android esamina i bug di sicurezza per determinare se esistono 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 al di fuori di Google Play, i dispositivi con Google Play Services possono anche utilizzare la funzione Verifica app per avvisare gli utenti di 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 punti di partenza:
- https://source.android.com/docs/security
- https://developer.android.com/training/articles/security-tips
Rapporti
A volte il team di sicurezza di Android pubblica report o white paper. Per ulteriori dettagli, vedere Rapporti sulla sicurezza .