Aggiornamenti e risorse sulla sicurezza

Il team di sicurezza Android è responsabile della gestione delle vulnerabilità della sicurezza scoperte nella piattaforma Android e in molte delle principali app Android fornite 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 modulo di vulnerabilità , ricerche accademiche pubblicate e prepubblicate, manutentori di progetti open source upstream, 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 in materia 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 potrebbero eventualmente essere resi visibili dopo che il problema è stato valutato o risolto. Se intendi 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.

Bug di triage

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 generalmente 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 non privilegiato.

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 più informazioni personali di utenti e/o mantiene l'integrità del sistema.

Ad esempio, un'applicazione Android con funzionalità che sarebbero vietate dal dominio SELinux untrusted_app o con accesso alle autorizzazioni privileged|signature .
Kernel del sistema operativo Funzionalità che:
  • fa parte del kernel
  • viene eseguito nello stesso contesto CPU del kernel (ad esempio, driver di dispositivo)
  • ha accesso diretto alla memoria del kernel (ad esempio, ai componenti hardware del dispositivo)
  • ha la capacità di caricare script in un componente del kernel (ad esempio, eBPF)
  • è uno dei pochi servizi utente considerati equivalenti al kernel (come apexd , bpfloader , init , ueventd e vold ).
Base hardware affidabile (THB) Componenti hardware discreti, generalmente sul SoC, che forniscono funzionalità critiche per i casi d'uso principali del dispositivo (come bande base cellulari, DSP, GPU e processori ML).
Catena del bootloader Un componente che configura il dispositivo all'avvio e quindi passa il controllo al sistema operativo Android.
Ambiente di esecuzione affidabile (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 opzionale progettato per essere protetto da tutti gli altri componenti del dispositivo e da attacchi fisici, come definito nell'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 dello sfruttamento riuscito
Critico
  • Esecuzione di codice arbitrario nel TEE o SE
  • Bypass di meccanismi software progettati per impedire il malfunzionamento di componenti software o hardware legati alla sicurezza (ad esempio, protezioni termiche)
  • Accesso remoto alle credenziali sensibili utilizzate per l'autenticazione del servizio remoto (ad esempio, password dell'account o token di connessione)
  • Esecuzione remota di codice arbitrario all'interno del contesto della banda base cellulare senza interazione da parte dell'utente (ad esempio, sfruttando un bug nel servizio radio cellulare)
  • Esecuzione remota di codice arbitrario in un contesto privilegiato, la catena del bootloader, THB o il kernel del sistema operativo
  • Bypass remoto dei requisiti di interazione dell'utente durante l'installazione del pacchetto o comportamento equivalente
  • Bypass remoto dei requisiti di interazione dell'utente per le impostazioni principali di sviluppatore, sicurezza o privacy
  • Negazione di servizio persistente remota (permanente, che richiede il reflash dell'intero sistema operativo o il ripristino delle impostazioni di fabbrica)
  • Bypass di avvio sicuro remoto
  • Accesso non autorizzato ai dati protetti dalla SE, compreso l'accesso consentito da chiavi deboli nella SE.
Alto
  • Un bypass completo di una funzionalità di sicurezza fondamentale (ad esempio, SELinux, FBE o seccomp )
  • Un bypass generale per una difesa in profondità o una tecnologia di mitigazione degli exploit nella catena del bootloader, TEE o SE
  • Un bypass generale per le protezioni del sistema operativo che rivelano la memoria o il contenuto dei file oltre i limiti dell'app, dell'utente o del profilo
  • Attacchi contro un SE che comportano il declassamento a un'implementazione meno sicura
  • Bypass della protezione del dispositivo/protezione del ripristino delle impostazioni di fabbrica/restrizioni dell'operatore
  • Bypassare i requisiti di interazione dell'utente garantiti dal TEE
  • Vulnerabilità crittografica che consente attacchi contro protocolli end-to-end, inclusi attacchi contro Transport Layer Security (TLS) e Bluetooth (BT).
  • Accesso locale alle credenziali sensibili utilizzate per l'autenticazione del servizio remoto (ad esempio, password dell'account o token di connessione)
  • Esecuzione di codice arbitrario locale in un contesto privilegiato, la catena del bootloader, THB o il kernel del sistema operativo
  • Bypass di avvio sicuro locale
  • Bypass della schermata di blocco
  • Bypass locale dei requisiti di interazione dell'utente per le impostazioni principali di sviluppatore, sicurezza o privacy
  • Bypass locale dei requisiti di interazione dell'utente durante l'installazione del pacchetto o comportamento equivalente
  • Denial of service locale persistente (permanente, che richiede il reflash dell'intero sistema operativo o il ripristino delle impostazioni di fabbrica)
  • Accesso remoto ai dati protetti (ovvero dati limitati a un contesto privilegiato)
  • Esecuzione remota di codice arbitrario in un contesto non privilegiato
  • Prevenzione remota dell'accesso al servizio cellulare o Wi-Fi senza interazione dell'utente (ad esempio, arresto anomalo del servizio radio cellulare con un pacchetto non valido)
  • Bypass remoto dei requisiti di interazione dell'utente (accesso a funzionalità o dati che dovrebbero richiedere l'avvio o l'autorizzazione dell'utente)
  • Prevenzione mirata dell’accesso ai servizi di emergenza
  • 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. Tieni presente che questo non si applica alla crittografia Wi-Fi (come WEP)
  • Accesso non autorizzato ai dati protetti dal TEE, incluso l'accesso abilitato da chiavi deboli nel TEE
Moderare
  • Un bypass generale per una difesa in profondità o la tecnologia di mitigazione degli exploit in un contesto privilegiato, THB o il kernel del sistema operativo
  • Un bypass generale per le protezioni del sistema operativo che rivelano lo stato del processo o i metadati oltre i limiti di app, utente o profilo
  • Bypassare la crittografia o l'autenticazione Wi-Fi
  • Vulnerabilità crittografica nelle primitive crittografiche standard che consente la perdita di testo in chiaro (non primitive utilizzate in TLS)
  • Accesso locale ai dati protetti (ovvero dati limitati a un contesto privilegiato)
  • Esecuzione di codice arbitrario locale in un contesto non privilegiato
  • Bypass locale dei requisiti di interazione dell'utente (accesso a funzionalità o dati che normalmente richiederebbero l'avvio o l'autorizzazione dell'utente)
  • Accesso remoto a dati non protetti (ovvero dati normalmente accessibili a qualsiasi app installata localmente)
  • Esecuzione remota di codice arbitrario in un contesto vincolato
  • Negazione del servizio del dispositivo temporaneo remoto (blocco o riavvio remoto)
Basso
  • Un bypass generale per una difesa approfondita a livello di utente o per sfruttare la tecnologia di mitigazione in un contesto non privilegiato
  • Bypass di un'autorizzazione di livello di protezione normale
  • Vulnerabilità crittografica nell'utilizzo non standard
  • Esclusione generale delle funzionalità di personalizzazione del dispositivo come Voice Match o Face Match
  • Documentazione errata che potrebbe portare a una vulnerabilità della sicurezza
  • Esecuzione di codice arbitrario locale in un contesto vincolato
  • Testo definito dal sistema che include una descrizione fuorviante che crea una falsa aspettativa di sicurezza
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 del codice sottostante possa rimanere
  • Qualsiasi vulnerabilità che richiede un file system non valido, se tale file system 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 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 è comunque possibile se il dispositivo è spento o non è stato sbloccato da quando è stato acceso -1 Gravità
Richiede l'accesso fisico ai componenti interni 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 modalità sviluppatore stessa). Non superiore a Basso
Se nessun dominio SELinux può condurre l'operazione secondo la 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 accedere fisicamente 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 remoti anche i vettori di attacco “prossimali”. 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 a eseguire un'app istantanea . I dispositivi associati associati verranno considerati locali. Ai fini della classificazione della gravità, il team di sicurezza Android considera locali anche i vettori di attacco fisico. 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 lanciare 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 l'access point a cui è connesso, non fa nulla per proteggere i restanti collegamenti nella catena tra il dispositivo e i server con cui comunica.

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 considerate meno gravi delle vulnerabilità in HTTPS/TLS: la sola crittografia Wi-Fi non è sufficiente per la maggior parte delle comunicazioni su Internet.

Autenticazione biometrica

L'autenticazione biometrica è un ambito impegnativo e anche i migliori sistemi possono essere ingannati da una quasi corrispondenza (vedi Blog degli sviluppatori Android: schermata di blocco e miglioramenti dell'autenticazione in Android 11 ). Questi livelli di gravità distinguono tra due classi di attacchi e intendono 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 concedere l'accesso al dispositivo in base ai residui lasciati sul sensore, si tratta di un attacco semplice che potrebbe essere eseguito su qualsiasi dispositivo vulnerabile. Non richiede alcuna conoscenza del proprietario del dispositivo. Dato che è generalizzabile e ha potenzialmente un impatto su un numero maggiore di utenti, questo attacco riceve la valutazione di gravità completa (ad esempio, Alta, 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, un bypass biometrico riceverebbe l'intera valutazione di gravità). Ma se un utente malintenzionato avesse bisogno di acquisire dati biometrici direttamente dal proprietario del dispositivo (ad esempio, una scansione a infrarossi del suo volto), si tratterebbe di 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 " Vulnerabilità tapjacking/overlay SYSTEM_ALERT_WINDOW su uno schermo non critico per la sicurezza " della pagina Bug senza impatto sulla sicurezza di 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 ad essere utilizzato da una persona fisica diversa. Ad esempio, è possibile assegnare un utente ospite temporaneo 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 di 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 risolti dal team di ingegneri Android. Bug di bassa gravità, bug in alcuni componenti o bug già noti pubblicamente possono essere risolti direttamente nel ramo principale AOSP disponibile pubblicamente; altrimenti verranno prima riparati nei nostri repository interni.

Il componente è anche un fattore nel modo in cui gli utenti ricevono 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 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 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 tuo 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 il rilascio dell'OTA 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.

Ricezione degli 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 dall'operatore che fornisce assistenza al dispositivo. Gli aggiornamenti dei dispositivi Google Pixel provengono dal team Google Pixel dopo aver superato una procedura di test di accettazione tecnica (TA) dell'operatore. Google pubblica anche immagini 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 tenta 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 sulle app che potrebbero essere potenzialmente dannose.

Altre risorse

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

Le informazioni sulla sicurezza sono presenti nei siti Android Open Source e per sviluppatori. Buoni posti per iniziare:

Rapporti

A volte il team di sicurezza Android pubblica report o white paper. Per ulteriori dettagli, vedere Rapporti sulla sicurezza .