Aggiornamenti e risorse per la sicurezza

Il team di sicurezza Android è responsabile della gestione delle vulnerabilità di sicurezza rilevate nella piattaforma Android e in molte delle app Android di base incluse nei dispositivi Android.

Il team di sicurezza 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 modulo per le vulnerabilità, ricerche accademiche pubblicate e in fase di pubblicazione, manutentori di progetti open source upstream, notifiche dei nostri partner produttori di dispositivi e problemi divulgati pubblicamente pubblicati su blog o social media.

Segnalare 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 per le vulnerabilità.

I bug contrassegnati come problemi di sicurezza non sono visibili esternamente, ma potrebbero diventarlo dopo la valutazione o la risoluzione del problema. Se prevedi di inviare una patch o un test della suite di test di compatibilità (CTS) per risolvere un problema di sicurezza, allegalo alla segnalazione di bug e attendi una risposta prima di caricare il codice su AOSP.

Valutare i bug

La prima attività nella gestione di una vulnerabilità di sicurezza consiste nell'identificare la gravità del bug e il componente di Android interessato. La gravità determina la priorità del problema, mentre il componente determina chi corregge il bug, chi viene avvisato e come viene implementata la correzione per gli 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 elabora in genere 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 con limitazioni in cui vengono fornite solo le autorizzazioni più minime.

Ad esempio, app attendibili che elaborano dati non attendibili in un ambiente sandbox.
Contesto senza privilegi Un ambiente di esecuzione tipico previsto dal codice senza privilegi.

Ad esempio, un'app per Android che viene eseguita in un dominio SELinux con l'attributo untrusted_app_all.
Contesto privilegiato Un ambiente di esecuzione privilegiato che potrebbe avere accesso a autorizzazioni elevate, gestisce più utenti PII e/o mantiene l'integrità del sistema.

Ad esempio, un'app per 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 della CPU del kernel (ad esempio, i driver del dispositivo)
  • ha accesso diretto alla memoria del kernel (ad esempio, i componenti hardware sul dispositivo)
  • ha la capacità di caricare script in un componente del kernel (ad esempio, eBPF)
  • è uno dei pochi servizi utente considerati equivalenti al kernel (ad esempio, apexd, bpfloader, init, ueventd, e vold).
Trusted Hardware Base (THB) Componenti hardware discreti, in genere sul SoC, che forniscono funzionalità essenziali per i casi d'uso principali del dispositivo (ad esempio, baseband cellulari, DSP, GPU e processori ML).
Bootloader Chain Un componente che configura il dispositivo all'avvio e poi passa il controllo al sistema operativo Android.
Trusted Execution Environment (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).
Secure Enclave / Secure Element (SE) Un componente hardware opzionale progettato per essere protetto da tutti gli altri componenti del dispositivo e da attacchi fisici, come definito in Introduzione agli elementi sicuri.

Ciò include il chip Titan-M presente in alcuni dispositivi Android.

Gravità

La gravità di un bug in genere riflette il potenziale danno che potrebbe verificarsi se un bug venisse sfruttato correttamente. Utilizza i seguenti criteri per determinare la gravità.

Classificazione Conseguenza dello sfruttamento riuscito
Critica
  • Esecuzione di codice arbitrario nel TEE o nell'SE
  • Elusione di meccanismi software progettati per impedire il malfunzionamento di componenti software o hardware correlati alla sicurezza (ad esempio, protezioni termiche)
  • Accesso remoto a credenziali sensibili utilizzate per l'autenticazione del servizio remoto (ad esempio, password dell'account o token di autenticazione)
  • Esecuzione di codice arbitrario remoto nel contesto della banda base cellulare senza interazione dell'utente (ad esempio, sfruttamento di un bug nel servizio di radiocomunicazione cellulare)
  • Esecuzione di codice arbitrario da remoto in un contesto privilegiato, la catena del bootloader, THB o il kernel del sistema operativo
  • Elusione remota 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
  • Denial of service persistente da remoto (permanente, che richiede il reflashing dell'intero sistema operativo o un ripristino dei dati di fabbrica)
  • Elusione dell'avvio protetto da remoto
  • Accesso non autorizzato ai dati protetti dall'SE, incluso l'accesso abilitato da chiavi deboli nell'SE.
Alto
  • Un bypass completo di una funzionalità di sicurezza di base (ad esempio SELinux, FBE o seccomp)
  • Un bypass generale per una tecnologia di difesa in profondità o di mitigazione degli exploit nella catena del bootloader, nel TEE o nell'SE
  • Un bypass generale per le protezioni del sistema operativo che rivelano i contenuti della memoria o dei file oltre i limiti di app, utente o profilo
  • Attacchi a un SE che comportano il downgrade a un'implementazione meno sicura
  • Pivot dal firmware bare metal compromesso raggiungibile da remoto (ad esempio, baseband, Communications Processor (CP)) al kernel del processore delle applicazioni (AP) o bypassare i meccanismi progettati per isolare il firmware bare metal dal kernel AP
  • Aggiramento della protezione del dispositivo, della protezione del ripristino dei dati di fabbrica (in Android 15 e versioni successive) o delle limitazioni dell'operatore
  • Aggiramento dei requisiti di interazione dell'utente protetti dal TEE
  • Vulnerabilità crittografica che consente attacchi contro protocolli end-to-end, inclusi attacchi contro Transport Layer Security (TLS) e Bluetooth (BT).
  • Accesso locale a credenziali sensibili utilizzate per l'autenticazione del servizio remoto (ad esempio password dell'account o token di autenticazione)
  • Esecuzione di codice arbitrario locale in un contesto privilegiato, nella catena del bootloader, in THB o nel kernel del sistema operativo
  • Aggiramento dell'avvio protetto locale
  • Ignorare la schermata di blocco
  • Elusione locale dei requisiti di interazione dell'utente per le impostazioni principali di sviluppatore, sicurezza o privacy
  • Elusione locale dei requisiti di interazione dell'utente durante l'installazione del pacchetto o comportamento equivalente
  • Negazione del servizio persistente locale (permanente, che richiede il reflashing dell'intero sistema operativo o il ripristino dei dati di fabbrica)
  • Accesso remoto ai dati protetti (ovvero dati limitati a un contesto privilegiato)
  • Esecuzione di codice arbitrario remoto in un contesto senza privilegi
  • Negazione del servizio da remoto per il servizio di rete mobile o Wi-Fi che persiste fino all'intervento dell'utente, attivata senza interazione utente (ad esempio, un arresto anomalo del servizio radio cellulare con un pacchetto non valido che non viene recuperato automaticamente e richiede un riavvio manuale o il riavvio del dispositivo).
  • Elusione remota 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 tramite un protocollo di rete non sicuro (ad esempio, HTTP e Bluetooth non criptato) quando il richiedente si aspetta una trasmissione sicura. Tieni presente che questa impostazione non si applica alla crittografia Wi-Fi (ad esempio WEP).
  • Accesso non autorizzato ai dati protetti dal TEE, incluso l'accesso abilitato da chiavi deboli nel TEE
Moderato
  • Un bypass generale per una tecnologia di difesa in profondità o di mitigazione degli exploit in un contesto privilegiato, THB o 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
  • Elusione della crittografia o dell'autenticazione Wi-Fi
  • Vulnerabilità crittografica nelle primitive crittografiche standard che consente la perdita di testo non crittografato (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 senza privilegi
  • Elusione 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 di codice arbitrario remoto in un contesto limitato
  • Negazione temporanea del servizio del dispositivo remoto (blocco o riavvio remoto)
Bassa
  • Un bypass generale per una difesa in profondità a livello di utente o una tecnologia di mitigazione degli exploit in un contesto non privilegiato
  • Ignorare un'autorizzazione di livello di protezione normale
  • Vulnerabilità crittografica in caso di utilizzo non standard
  • Elusione generale delle funzionalità di personalizzazione sul dispositivo, ad esempio Voice Match o Face Match
  • Documentazione errata che potrebbe comportare una vulnerabilità di sicurezza
  • Esecuzione di codice arbitrario locale in un contesto vincolato
  • Testo definito dal sistema che include una descrizione ingannevole che crea una falsa aspettativa di sicurezza
Impatto sulla sicurezza trascurabile (NSI)
  • Una vulnerabilità il cui impatto è stato mitigato da uno o più modificatori della classificazione o modifiche all'architettura specifiche della versione, in modo che la gravità effettiva sia inferiore a Bassa, anche se il problema del codice sottostante potrebbe rimanere
  • Qualsiasi vulnerabilità che richieda un file system danneggiato, se questo file system viene sempre adottato/criptato prima dell'uso.
  • Negazione temporanea locale del servizio, ad esempio quando la condizione può essere risolta riavviando il dispositivo o disinstallando l'app che ha attivato il problema.

Modificatori della gravità

Sebbene la gravità delle vulnerabilità di sicurezza sia spesso facile da identificare, le valutazioni possono variare 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à media se la vulnerabilità sottostante è media o superiore
Richiede l'accesso fisico ai componenti interni del dispositivo ed è comunque possibile se il dispositivo è spento o non è stato sbloccato dall'accensione -1 Gravità
Richiede l'accesso fisico ai componenti interni del dispositivo mentre è acceso ed è stato precedentemente sbloccato -2 Gravità
Un attacco locale che richiede lo sblocco della catena del bootloader Non superiore a Bassa
Un attacco locale che richiede la modalità sviluppatore o qualsiasi impostazione persistente della modalità sviluppatore attualmente abilitata sul dispositivo (e non è un bug della modalità sviluppatore stessa). Non superiore a Bassa
Se nessun dominio SELinux può eseguire l'operazione in base a SEPolicy fornita da Google Impatto sulla sicurezza trascurabile

Locale, prossimale e remoto

Un vettore d'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'email, ricevendo un messaggio SMS o connettendosi a una rete ostile.

I vettori di attacco prossimali sono considerati remoti. Sono inclusi bug che possono essere sfruttati solo da un 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 basati su banda ultralarga (UWB) e NFC come prossimali e quindi remoti.

Gli attacchi locali richiedono che l'aggressore abbia accesso precedente alla vittima. In un esempio ipotetico solo software, questo potrebbe avvenire tramite un'app dannosa installata dalla vittima o un'app istantanea che ha acconsentito a eseguire.

I dispositivi accoppiati correttamente (come i dispositivi complementari Bluetooth) sono considerati locali. Distinguiamo tra un dispositivo accoppiato e un dispositivo che partecipa a un flusso di accoppiamento.

  • I bug che riducono la capacità dell'utente di identificare l'altro dispositivo con cui viene eseguito l'accoppiamento (ad es. autenticazione) sono considerati prossimali e quindi remoti.
  • I bug che si verificano durante il flusso di accoppiamento, ma prima che sia stato stabilito il consenso dell'utente (ovvero l'autorizzazione), sono considerati prossimali e quindi remoti.
  • I bug che si verificano dopo che è stato stabilito il consenso dell'utente sono considerati locali, anche se l'accoppiamento alla fine non riesce.

I vettori di attacco fisico sono considerati locali. Sono inclusi bug che possono essere sfruttati solo da un 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. Poiché è comune che i dispositivi vengano sbloccati mentre sono collegati alla porta USB, gli attacchi che richiedono una connessione USB hanno la stessa gravità indipendentemente dal fatto che il dispositivo debba essere sbloccato o meno.

Sicurezza della rete

Android presuppone che tutte le reti siano ostili e possano 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 a cui è connesso, non fa nulla per proteggere i collegamenti rimanenti 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 all'origine, 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 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 è un campo difficile e anche i sistemi migliori possono essere ingannati da una corrispondenza quasi perfetta (vedi Blog per sviluppatori Android: miglioramenti della schermata di blocco e dell'autenticazione in Android 11). Queste valutazioni della 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 bypassare l'autenticazione biometrica in modo generalizzabile, senza dati biometrici di alta qualità del proprietario. Se, ad esempio, un malintenzionato può appoggiare un pezzo di gomma su un sensore di impronte digitali e questo concede l'accesso al dispositivo in base ai residui rimasti sul sensore, si tratta di un attacco semplice che potrebbe essere eseguito su qualsiasi dispositivo vulnerabile. Non richiede alcuna conoscenza del proprietario del dispositivo. Poiché è generalizzabile e potrebbe interessare un numero maggiore di utenti, questo attacco riceve la classificazione di gravità completa (ad esempio, Alta, per un bypass della schermata di blocco).

L'altra classe di attacchi in genere coinvolge uno strumento di attacco di presentazione (spoofing) 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 riceverà la valutazione di gravità completa). Tuttavia, se un malintenzionato dovesse acquisire dati biometrici direttamente dal proprietario del dispositivo (ad esempio, una scansione a infrarossi del volto), si tratta di un ostacolo sufficientemente significativo da limitare il numero di persone interessate dall'attacco, quindi è presente un modificatore -1.

SYSTEM_ALERT_WINDOW e tapjacking

Per informazioni sulle nostre norme relative a SYSTEM_ALERT_WINDOW e tapjacking, consulta la sezione "Vulnerabilità di tapjacking/sovrapposizione SYSTEM_ALERT_WINDOW su una schermata non critica per la sicurezza" della pagina Bugs with no security impact di BugHunter University.

Sicurezza multiutente in Android Automotive OS

Android Automotive OS adotta un modello di sicurezza multiutente diverso dagli altri fattori di forma. Ogni utente Android deve 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 di rete Wi-Fi e cellulare.

Componente interessato

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

I bug nel codice AOSP vengono corretti dal team tecnico di Android nei nostri repository interni.

Il componente è anche un fattore che determina la modalità di ricezione degli aggiornamenti da parte degli utenti. Un bug nel framework o nel kernel richiede un aggiornamento firmware OTA (over-the-air) che ogni OEM deve eseguire. 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.

Notificare ai partner

Quando una vulnerabilità della sicurezza in AOSP viene corretta in un Bollettino sulla sicurezza di Android, comunicheremo ai partner Android i dettagli del problema e forniremo le patch. L'elenco delle versioni supportate per il backport cambia a ogni nuova release di Android. Contatta il produttore del dispositivo per l'elenco dei dispositivi supportati.

Rilasciare il codice in AOSP

Se il bug di sicurezza si trova in un componente AOSP, la correzione viene inviata ad AOSP dopo che l'OTA è rilasciata agli utenti.

Ricevere aggiornamenti di Android

Gli aggiornamenti del sistema Android vengono generalmente distribuiti ai dispositivi tramite pacchetti di aggiornamento OTA. Questi aggiornamenti potrebbero provenire dall'OEM che ha prodotto il dispositivo o dall'operatore che fornisce il servizio 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 del produttore per Pixel che possono essere caricate lateralmente sui dispositivi.

Aggiornare i 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 quelle che tentano di sfruttare un bug di sicurezza. Per le app installate da fonti esterne a Google Play, i dispositivi con Google Play Services potrebbero utilizzare anche la funzionalità Verifica app per avvisare gli utenti in merito alle app potenzialmente dannose.

Altre risorse

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

Le informazioni sulla sicurezza sono disponibili nei siti Android Open Source e per sviluppatori. Buoni punti di partenza:

Report

A volte il team per la sicurezza di Android pubblica report o white paper. Per ulteriori dettagli, vedi Report sulla sicurezza.