Aggiornamenti e risorse per la sicurezza

Il team di sicurezza di Android è responsabile della gestione delle vulnerabilità di sicurezza rilevate 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à 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 modello di Problemi di sicurezza di Android , ricerche accademiche pubblicate e pre-pubblicate, 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ò informare il team di sicurezza Android di potenziali problemi di sicurezza attraverso il modulo di segnalazione della vulnerabilità della sicurezza .

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 si prevede di inviare una patch o un test CTS (Compatibility Test Suite) per risolvere un problema di sicurezza, allegarlo alla segnalazione di bug e attendere una risposta prima di caricare il codice su AOSP.

Triaging bugs

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 viene avvisato e come viene distribuita la correzione agli utenti.

Tipi di processo

Questa tabella illustra 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	Digitare la definizione
Processo vincolato	Un processo che viene eseguito in un dominio SELinux altamente limitato. O Un processo significativamente più limitato di un'app normale.
Processo senza privilegi	Un'app o un processo di terze parti. O Un'app o un processo che viene eseguito nel dominio SELinux `untrusted_app` .
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).
Trusted computing base (TCB)	La funzionalità che fa parte del kernel, viene eseguita nello stesso contesto CPU del kernel (come i driver di dispositivo), ha accesso diretto alla memoria del kernel (come componenti hardware sul dispositivo), ha la capacità di caricare script in un componente del kernel ( ad esempio, eBPF), il processore in banda base, o è uno dei pochi servizi per l'utente considerati equivalenti al kernel: `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.
Elemento sicuro (SE)	Un componente opzionale progettato per essere protetto da tutti gli altri componenti sul dispositivo e dagli attacchi fisici, come definito in 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 di uno sfruttamento riuscito
critico	Accesso non autorizzato ai dati protetti dalla SE Esecuzione di codice arbitrario in 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 reflashing 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, sicurezza o impostazioni sulla privacy Bypass di avvio sicuro remoto Bypass dei meccanismi di sicurezza progettati per prevenire malfunzionamenti dei componenti hardware critici (ad esempio protezioni termiche)
alto	Bypass di avvio sicuro locale Un bypass completo di una funzionalità di sicurezza principale (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 protetti dal TEE Attacchi contro un SE che si traducono in 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 reflashing dell'intero sistema operativo o ripristino delle impostazioni di fabbrica) Bypass remoto dei requisiti di interazione dell'utente (accesso a funzionalità o dati che normalmente richiederebbero l'avvio dell'utente o l'autorizzazione dell'utente) Trasmissione di informazioni riservate su un protocollo di rete non sicuro (ad esempio HTTP e Bluetooth non crittografato) quando il richiedente si aspetta una trasmissione protetta (notare che ciò non si applica alla crittografia Wi-Fi, come WEP) Un bypass generale per una difesa approfondita o sfruttamento della tecnologia di mitigazione nel bootloader o TEE Un bypass generale per le protezioni del sistema operativo che isola i dati delle app o i profili utente l'uno dall'altro Bypass locale dei requisiti di interazione dell'utente per qualsiasi sviluppatore, sicurezza o impostazioni sulla privacy Vulnerabilità crittografica nella sicurezza del livello di trasporto standard (TLS) che consente attacchi man-in-the-middle Bypass schermata di blocco Bypass della protezione del dispositivo / protezione ripristinata in fabbrica / restrizioni del vettore Prevenzione mirata dell'accesso ai servizi di emergenza Bypass dei requisiti di interazione dell'utente che sono garantiti dal TEE
Moderare	Esecuzione di codice arbitrario remoto in un processo vincolato Denial of service remoto temporaneo del dispositivo (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 nel TCB Bypass di restrizioni su un processo vincolato Accesso remoto a dati non protetti (dati normalmente accessibili a qualsiasi app installata localmente) Accesso locale ai dati protetti (dati limitati a un processo privilegiato) Bypass locale dei requisiti di interazione dell'utente (accesso a funzionalità che normalmente richiederebbe l'avvio dell'utente o l'autorizzazione dell'utente) Vulnerabilità crittografica nelle primitive crittografiche standard che consente la fuoriuscita del testo in chiaro (non delle primitive utilizzate in TLS) Bypassare la crittografia o l'autenticazione Wi-Fi in un modo che consenta a un utente malintenzionato di connettersi al dispositivo Android quando funge da hotspot o al punto di accesso alla rete (AP) a cui è connesso il dispositivo
Basso	Esecuzione di codice arbitrario locale in un processo vincolato Vulnerabilità crittografica nell'uso non standard Un bypass generale per una difesa a livello di utente in profondità o sfruttare la tecnologia di mitigazione in un processo senza privilegi
Nessun impatto sulla sicurezza (NSI)	Una vulnerabilità il cui impatto è stato mitigato da uno o più modificatori di classificazione o modifiche dell'architettura specifica della versione in modo tale che la gravità effettiva sia inferiore a Basso, sebbene il problema del codice sottostante possa rimanere

Modificatori di rating

Sebbene la gravità delle vulnerabilità della sicurezza sia spesso facile da identificare, le classificazioni possono variare 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à
Le configurazioni del compilatore o della piattaforma attenuano una vulnerabilità nel codice sorgente	Gravità moderata se la vulnerabilità sottostante è Moderata o superiore
Richiede l'accesso fisico agli interni del dispositivo ed è ancora possibile se il telefono è spento o non è stato sbloccato da quando è acceso	-1 Gravità
Richiede l'accesso fisico agli 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 la Modalità sviluppatore o qualsiasi impostazione persistente della modalità sviluppatore per essere abilitata sul dispositivo (e non è un bug in Modalità sviluppatore).	Non superiore a Basso
Se nessun dominio SELinux può eseguire l'operazione con SEPolicy fornito da Google	Nessun impatto sulla sicurezza

Locale 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 i bug che possono essere attivati accedendo a una pagina Web, leggendo un'e-mail, ricevendo un messaggio SMS o connettendosi a una rete ostile. Ai fini dei nostri livelli di gravità, il team di sicurezza di Android considera anche i vettori di attacco "prossimale" 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. Il team di sicurezza di Android considera gli attacchi basati su NFC come prossimali e quindi remoti.

Gli attacchi locali richiedono alla vittima di eseguire un'app, installando ed eseguendo un'app o acconsentendo a eseguire un'app istantanea . Ai fini della valutazione della gravità, il team di sicurezza di Android considera anche i vettori di attacco fisico 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; è comune che i dispositivi vengano sbloccati mentre sono collegati a USB.

Sicurezza Wi-Fi

Android presume che tutte le reti siano ostili e potrebbero iniettare attacchi o spiare il traffico. Per garantire che gli avversari a livello di rete non aggirino la protezione dei dati delle app, Android incoraggia vivamente che tutto il traffico di rete utilizzi la crittografia end-to-end. La crittografia a livello di collegamento non è sufficiente.

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 sono stati corretti dal team di ingegneri Android. Bug a bassa gravità, bug in alcuni componenti o bug già noti pubblicamente possono essere corretti direttamente nel ramo master AOSP pubblicamente disponibile; altrimenti vengono prima riparati 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 spingere. Un bug in un'app o in 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.

Partner di notifica

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. Contattare 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 OTA è stato rilasciato agli utenti. Le correzioni per problemi a bassa gravità possono essere inviate direttamente al ramo master AOSP prima che una correzione sia disponibile per i dispositivi tramite un OTA.

Ricezione di aggiornamenti Android

Gli aggiornamenti al sistema Android vengono generalmente consegnati ai dispositivi tramite pacchetti di aggiornamento OTA. Questi aggiornamenti possono provenire dall'OEM che ha prodotto il dispositivo o dal corriere che fornisce assistenza al dispositivo. Gli aggiornamenti dei dispositivi Google Pixel provengono dal team di Google Pixel dopo aver seguito una procedura di test di accettazione tecnica dell'operatore. Google pubblica anche immagini Pixel di fabbrica 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 potenzialmente dannose.

Altre risorse

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

Esistono informazioni sulla sicurezza in tutti i siti Android Open Source e Developer. Buoni posti da cui iniziare:

Rapporti

A volte il team di sicurezza di Android pubblica report o white paper. Vedi Rapporti di sicurezza per maggiori dettagli.