Aggiornamenti e risorse per la sicurezza

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

Il team di sicurezza di Android individua le vulnerabilità di sicurezza tramite ricerche interne e risponde anche ai bug segnalati da terze parti. Le fonti di bug esterni includono i problemi segnalati tramite il modulo per le vulnerabilità, la ricerca accademica pubblicata e prepubblicata, i manutentori dei progetti open source upstream, le notifiche dei nostri partner produttori di dispositivi e i problemi divulgati pubblicamente pubblicati su blog o social media.

Segnalare problemi di sicurezza

Qualsiasi sviluppatore, utente Android o ricercatore di sicurezza può segnalare 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 all'esterno, ma possono essere resi visibili dopo la valutazione o la risoluzione del problema. Se prevedi di inviare una patch o un test della Compatibility Test Suite (CTS) per risolvere un problema di sicurezza, allegala alla segnalazione di bug e attendi una risposta prima di caricare il codice in AOSP.

Classificare i bug

Il primo compito per gestire una vulnerabilità di sicurezza è 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 riceve una notifica e come viene implementata la correzione per gli utenti.

Tipi di contesto

Questa tabella illustra le definizioni dei contesti di sicurezza hardware e software. Il contesto può essere definito in base alla sensibilità dei dati che in genere vengono trattati o all'area in cui viene eseguito. Non tutti i contesti di sicurezza sono applicabili a tutti i sistemi. Questa tabella è ordinata dal privilegio minimo al massimo.

Tipo di contesto Definizione del tipo
Contesto vincolato Un ambiente di esecuzione limitato in cui vengono fornite solo le autorizzazioni 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 con privilegi Un ambiente di esecuzione privilegiato che potrebbe avere accesso a autorizzazioni elevate, gestire più PII degli utenti e/o mantenere l'integrità del sistema.

Ad esempio, un'app per Android con funzionalità vietate dal dominio untrusted_app SELinux 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 di dispositivo)
  • ha accesso diretto alla memoria del kernel (ad esempio, componenti hardware sul dispositivo)
  • abbia 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, generalmente sul SoC, che forniscono funzionalità fondamentali per i casi d'uso principali del dispositivo (ad esempio, basi di banda cellulare, DSP, GPU e processori ML).
Catena del bootloader 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 facoltativo progettato per essere protetto da tutti gli altri componenti del dispositivo e dagli attacchi fisici, come definito in Introduzione agli elementi sicuri.

È incluso il chip Titan-M presente in alcuni dispositivi Android.

Gravità

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

Classificazione Conseguenza di uno sfruttamento riuscito
Critica
  • Esecuzione di codice arbitrario nel TEE o nel SE
  • Bypass dei meccanismi software progettati per impedire il malfunzionamento di componenti hardware o software correlati alla sicurezza (ad esempio le protezioni termiche)
  • Accesso remoto a credenziali sensibili utilizzate per l'autenticazione dei servizi remoti (ad es. password dell'account o token bearer)
  • Esecuzione di codice arbitrario da remoto nel contesto della banda di base cellulare senza interazione dell'utente (ad esempio, sfruttando un bug nel servizio radio cellulare)
  • Esecuzione di codice arbitrario da remoto in un contesto privilegiato, nella catena del bootloader, nel THB o nel kernel del sistema operativo
  • Bypass remoto dei requisiti di interazione utente per l'installazione del pacchetto o comportamento equivalente
  • Bypass da remoto dei requisiti di interazione utente per le impostazioni di privacy, sicurezza o sviluppatore di base
  • Denial of Service remoto persistente (permanente, che richiede il riflash dell'intero sistema operativo o un ripristino dei dati di fabbrica)
  • Bypass 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 difesa in profondità o una tecnologia di mitigazione degli exploit nella catena di bootloader, nel TEE o nel SE
  • Un bypass generale per le protezioni del sistema operativo che rivela i contenuti della memoria o dei file al di là dei confini di app, utente o profilo
  • Attacchi a un SE che comportano il downgrade a un'implementazione meno sicura
  • Passare dal firmware bare-metal compromesso raggiungibile da remoto (ad esempio, baseband, processore di comunicazione (CP)) al kernel del processore di app (AP) o bypassare i meccanismi progettati per isolare il firmware bare-metal dal kernel AP
  • Bypass della protezione del dispositivo, della protezione del ripristino dei dati di fabbrica o delle limitazioni dell'operatore
  • Bypass dei requisiti di interazione con l'utente protetti dal TEE
  • Vulnerabilità crittografica che consente attacchi contro i protocolli end-to-end, tra cui attacchi contro Transport Layer Security (TLS) e Bluetooth (BT).
  • Accesso locale alle credenziali sensibili utilizzate per l'autenticazione dei servizi remoti (ad esempio, password dell'account o token bearer)
  • Esecuzione di codice arbitrario locale in un contesto privilegiato, nella catena del bootloader, nel THB o nel kernel del sistema operativo
  • Bypass dell'avvio protetto locale
  • Bypass della schermata di blocco
  • Bypass locale dei requisiti di interazione utente per le impostazioni di sicurezza, privacy o per gli sviluppatori principali
  • Bypass locale dei requisiti di interazione utente per l'installazione del pacchetto o comportamento equivalente
  • Denial of Service locale persistente (permanente, che richiede il riflash dell'intero sistema operativo o il ripristino dei dati di fabbrica)
  • Accesso remoto a dati protetti (ovvero dati limitati a un contesto privilegiato)
  • Esecuzione di codice arbitrario da remoto in un contesto senza privilegi
  • Prevenzione da remoto dell'accesso al servizio di rete mobile o Wi-Fi senza interazione dell'utente (ad esempio, arresto anomalo del servizio radio cellulare con un pacchetto con formato non valido)
  • Bypass remoto dei requisiti di interazione utente (accesso a funzionalità o dati che devono 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 l'utente che effettua la richiesta si aspetta una trasmissione sicura. Tieni presente che questo 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 difesa in profondità o una tecnologia di mitigazione degli exploit in un contesto privilegiato, THB o nel kernel del sistema operativo
  • Un bypass generale per le protezioni del sistema operativo che rivelano lo stato del processo o i metadati oltre i confini di app, utente o profilo
  • Bypassare la crittografia o l'autenticazione Wi-Fi
  • Vulnerabilità crittografica nelle primitive di crittografia standard che consente la fuga di testo non cifrato (non le 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
  • Bypass locale dei requisiti di interazione 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 da remoto in un contesto limitato
  • Denial of Service temporaneo del dispositivo da remoto (blocco o riavvio da remoto)
Bassa
  • Un bypass generale per una difesa approfondita a livello di utente o una tecnologia di mitigazione degli exploit in un contesto senza privilegi
  • Bypass di un'autorizzazione di un normale livello di protezione.
  • Vulnerabilità crittografica in caso di utilizzo non standard
  • Bypass generale delle funzionalità di personalizzazione sul dispositivo, come Voice Match o Face Match
  • Documentazione errata che potrebbe comportare una vulnerabilità di sicurezza
  • Esecuzione di codice arbitrario locale in un contesto limitato
  • Testo definito dal sistema che include una descrizione fuorviante 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 da modifiche dell'architettura specifiche della versione in modo che la gravità effettiva sia inferiore a Bassa, anche se il problema del codice sottostante potrebbe persistere
  • Qualsiasi vulnerabilità che richiede un file system con formato non corretto, se il file system viene sempre adottato/criptato prima dell'uso.
  • Negozio di servizio temporaneo locale, ad esempio quando la condizione può essere risolta riavviando il dispositivo o disinstallando l'app che ha attivato il problema.

Modificatori delle tariffe

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

Motivo Effetto
Richiede l'esecuzione come contesto con privilegi per eseguire l'attacco (non applicabile a TEE, SE e ipervisori come pKVM) Gravità -1
I dettagli specifici della vulnerabilità limitano l'impatto del problema Gravità -1
Bypass dell'autenticazione biometrica che richiede informazioni biometriche direttamente dal proprietario del dispositivo Gravità -1
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 agli elementi interni del dispositivo ed è ancora possibile se il dispositivo è spento o non è stato sbloccato dopo l'accensione Gravità -1
Richiede l'accesso fisico agli elementi interni del dispositivo quando è acceso e è stato precedentemente sbloccato Gravità -2
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 eventuali impostazioni permanenti della modalità sviluppatore siano attualmente attive sul dispositivo (e non si tratta di un bug della modalità sviluppatore stessa). Non superiore a Basso
Se nessun dominio SELinux può eseguire l'operazione in base alle norme SEPolicy fornite da Google Impatto sulla sicurezza trascurabile

Locale, nelle vicinanze e remoto

Un vettore di attacco remoto indica che il bug può essere sfruttato senza installare un'app o senza accesso fisico a un dispositivo. Sono inclusi i bug che possono essere attivati visitando una pagina web, leggendo un'email, ricevendo un messaggio SMS o connettendosi a una rete ostile.

I vettori di attacco proximal sono considerati remoti. Sono inclusi i bug che possono essere sfruttati solo da un malintenzionato fisicamente vicino al dispositivo di destinazione, ad esempio un bug che richiede l'invio di pacchetti Wi-Fi o Bluetooth con formato non corretto. Consideriamo gli attacchi basati su banda ultralarga (UWB) e NFC come prossimi e quindi remoti.

Gli attacchi locali richiedono che l'aggressore abbia accesso preventivo alla vittima. In un ipotetico esempio solo software, questo potrebbe avvenire tramite un'app dannosa installata dalla vittima o un'app istantanea per cui la vittima ha dato il suo consenso all'esecuzione.

I dispositivi accoppiati correttamente (ad esempio i dispositivi Bluetooth companion) sono considerati locali. Distinguiamo un dispositivo accoppiato da un dispositivo che partecipa a un flusso di accoppiamento.

  • I bug che riducono la capacità dell'utente di identificare l'altro dispositivo con cui è accoppiato (ad es. l'autenticazione) sono considerati prossimi 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 prossimi e quindi remoti.
  • I bug che si verificano dopo che è stato stabilito il consenso dell'utente sono considerati locali, anche se l'accoppiamento non va a buon fine.

I vettori di attacco fisici sono considerati locali. Sono inclusi i bug che possono essere sfruttati solo da un malintenzionato che ha accesso fisico al dispositivo, ad esempio un bug nella schermata di blocco o uno che richiede il collegamento di un cavo USB. Poiché è normale che i dispositivi siano sbloccati quando 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 potrebbero iniettare attacchi o spiare il traffico. Sebbene la sicurezza a livello di link (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 link rimanenti della catena tra il dispositivo e i server con cui comunica.

Al contrario, HTTPS protegge in genere l'intera comunicazione end-to-end, criptando i dati alla fonte, quindi decriptandoli e verificandoli solo quando raggiungono la destinazione finale. Per questo motivo, le vulnerabilità che compromettono la sicurezza della rete a livello di link sono considerate 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 ambito impegnativo e anche i sistemi migliori possono essere ingannati da una corrispondenza quasi perfetta (vedi Blog per sviluppatori Android: miglioramenti alla schermata di blocco e all'autenticazione in Android 11). Queste classificazioni della 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à del proprietario. Se, ad esempio, un malintenzionato riesce a posizionare un chewing-gum su un sensore di impronte digitali e ottiene l'accesso al dispositivo in base ai residui lasciati sul sensore, si tratta di un semplice attacco che potrebbe essere eseguito su qualsiasi dispositivo vulnerabile. Non richiede alcuna conoscenza del proprietario del dispositivo. Poiché è generalizzabile e potenzialmente interessa 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 in genere 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 una persona sui social media è sufficiente per ingannare l'autenticazione biometrica, un bypass biometrico riceverà la valutazione di gravità massima). Tuttavia, se un malintenzionato avesse bisogno di acquisire i dati biometrici direttamente dal proprietario del dispositivo (ad esempio, una scansione a infrarossi del suo viso), si tratta di una barriera sufficientemente significativa 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/overlay SYSTEM_ALERT_WINDOW in una schermata non critica per la sicurezza" della pagina Bug senza impatto sulla sicurezza di BugHunter University.

Sicurezza multiutente in Android Automotive OS

Android Automotive OS adotta un modello di sicurezza multiutente diverso da quello degli 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 supportare casi d'uso come questo, per impostazione predefinita gli utenti hanno accesso ai componenti necessari per utilizzare il veicolo, ad esempio le impostazioni di Wi-Fi e rete mobile.

Componente interessato

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

I bug nel codice AOSP vengono corretti dal team di ingegneri di Android. I bug di bassa gravità, i bug di determinati componenti o i bug già noti al pubblico possono essere corretti direttamente nel ramo principale AOSP disponibile pubblicamente; in caso contrario, vengono corretti in primo luogo nei nostri repository interni.

Il componente è anche un fattore che influisce sulla modalità di ricezione degli aggiornamenti da parte degli utenti. 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 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.

Avvisare i partner

Quando una vulnerabilità di sicurezza in AOSP viene risolta in un bollettino sulla sicurezza di Android, informeremo i partner Android dei dettagli del problema e forniremo le patch. L'elenco delle versioni supportate dal backport cambia con ogni nuova release di Android. Contatta il produttore del dispositivo per avere 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 è stata rilasciata 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 aggiornamento OTA.

Ricevere aggiornamenti di Android

In genere, gli aggiornamenti al sistema Android vengono inviati ai dispositivi tramite pacchetti di aggiornamento OTA. Questi aggiornamenti possono 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 di Google Pixel dopo aver superato una procedura di test di accettazione tecnica (AT) dell'operatore. Google pubblica anche immagini del produttore di 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 diverse da Google Play, i dispositivi con Google Play Services possono utilizzare anche la funzionalità Verifica app per avvisare gli utenti delle 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 Android for Developers. Ecco alcuni buoni modi per iniziare:

Report

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