Aggiornamenti di sicurezza e risorse

Il team di sicurezza di 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 rileva vulnerabilità di sicurezza attraverso ricerche interne e risponde anche a bug segnalati da terze parti. Fonti di bug esterni includono problemi segnalati attraverso il modello di problema di sicurezza di Android , pubblicato e prepublished ricerca accademica, a monte aperti manutentori progetto di origine, le notifiche dai nostri partner di produttore del dispositivo, e pubblicamente le questioni divulgate pubblicati su blog o social media.

Segnalazione di problemi di sicurezza

Qualsiasi sviluppatore, l'utente Android, o ricercatore di sicurezza in grado di comunicare al team di sicurezza di Android di potenziali problemi di sicurezza attraverso il modulo di segnalazione vulnerabilità di 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 prevedi di inviare una patch o un test di Compatibility Test Suite (CTS) per risolvere un problema di sicurezza, allegalo alla segnalazione di bug e attendi una risposta prima di caricare il codice su AOSP.

Individuazione 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 "sandbox" per l'elaborazione di dati non attendibili senza consentire l'accesso al sistema sottostante.
Contesto non privilegiato Un tipico ambiente di esecuzione previsto dal codice senza privilegi.

Ad esempio, un'applicazione Android che viene eseguito in un dominio SELinux con il untrusted_app_all attributo.
Contesto privilegiato Un ambiente di esecuzione privilegiato che può avere accesso a permessi elevati, gestisce PII di più utenti e/o mantiene l'integrità del sistema.

Ad esempio, un'applicazione Android con funzionalità che sarebbe vietato dalla SELinux untrusted_app dominio o con l'accesso ai privileged|signature i permessi.
Base di calcolo affidabile (TCB) La funzionalità che fa parte del kernel, viene eseguita nello stesso contesto della CPU del kernel (come i driver di dispositivo), ha accesso diretto alla memoria del kernel (come i componenti hardware sul dispositivo), ha la capacità di caricare script in un componente del kernel ( per esempio, eBPF), i processori di comunicazione, o è uno di una manciata di servizi per l'utente che è considerato equivalente kernel: apexd , bpfloader , init , ueventd e vold .
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 ostile (ad esempio, TrustZone e Hypervisor).
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 nella Introduzione al Elementi sicure .

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

Gravità

La gravità di un bug riflette generalmente il potenziale danno che potrebbe verificarsi se un bug fosse sfruttato con successo. Utilizzare i seguenti criteri per determinare la gravità.

Valutazione Conseguenza dello sfruttamento di successo
critico
  • Accesso non autorizzato ai dati protetti dalla SE
  • Esecuzione di codice arbitrario nel TEE o SE
  • Esecuzione remota di codice arbitrario in un contesto privilegiato, la catena del bootloader o il TCB
  • Denial of Service remoto persistente (permanente o che richiede il reflash 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
  • Esclusione remota dei requisiti di interazione dell'utente per qualsiasi sviluppatore, impostazioni di sicurezza o privacy
  • Bypass di avvio sicuro remoto
  • Bypass di meccanismi atti a prevenire 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 al portatore)
Alto
  • Bypass di avvio sicuro locale
  • Un bypass completo di una funzionalità di sicurezza di base (come SELinux, FDE o seccomp)
  • Esecuzione remota di codice arbitrario in un contesto non privilegiato
  • Esecuzione di codice arbitrario locale in un contesto privilegiato, la catena del bootloader o il TCB
  • Accesso non autorizzato ai dati protetti dal TEE
  • Attacchi contro un SE che comportano il downgrade a un'implementazione meno sicura
  • Esclusione locale dei requisiti di interazione dell'utente sull'installazione del pacchetto o comportamento equivalente
  • Accesso remoto ai dati protetti (dati limitati a un contesto privilegiato)
  • Denial of Service locale persistente (permanente o che richiede il reflash dell'intero sistema operativo o il ripristino dei dati di fabbrica)
  • Esclusione remota 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 sensibili su un protocollo di rete non sicuro (ad esempio HTTP e Bluetooth non crittografato) quando il richiedente si aspetta una trasmissione sicura (nota che ciò non si applica alla crittografia Wi-Fi, come WEP)
  • Un bypass generale per una difesa in profondità o per sfruttare la tecnologia di mitigazione nella catena del bootloader, TEE o SE
  • Un bypass generale per le protezioni del sistema operativo che isolano i dati delle app o i profili utente l'uno dall'altro
  • Esclusione locale dei requisiti di interazione dell'utente per qualsiasi sviluppatore, impostazioni di sicurezza o privacy
  • Vulnerabilità crittografica che consente attacchi contro protocolli end-to-end, inclusi attacchi contro la sicurezza del livello di trasporto (TLS) e Bluetooth (BT).
  • Esclusione della schermata di blocco
  • Bypass della protezione del dispositivo/protezione del ripristino delle impostazioni di fabbrica/restrizioni dell'operatore
  • Prevenzione mirata dell'accesso ai servizi di emergenza
  • Bypassare i requisiti di interazione dell'utente protetti dal TEE
  • Prevenzione remota dell'accesso al servizio cellulare senza interazione dell'utente (ad esempio, arresto anomalo del servizio radio cellulare con un pacchetto non valido)
  • Accesso locale alle credenziali sensibili utilizzate per l'autenticazione del servizio remoto (ad esempio, password dell'account o token al portatore)
Moderare
  • Esecuzione remota di codice arbitrario in un contesto vincolato
  • Denial of Service del dispositivo temporaneo remoto (blocco remoto o riavvio)
  • Esecuzione di codice arbitrario locale in un contesto non privilegiato
  • Un bypass generale per una difesa in profondità o sfruttare la tecnologia di mitigazione in un contesto privilegiato o il TCB
  • Bypassare le 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 contesto privilegiato)
  • Esclusione locale dei requisiti di interazione dell'utente (accesso a funzionalità o dati che normalmente richiederebbero l'avvio dell'utente o l'autorizzazione dell'utente)
  • Vulnerabilità crittografica nelle primitive crittografiche standard che consente la fuoriuscita di testo in chiaro (non primitive utilizzate in TLS)
  • Bypassare la crittografia o l'autenticazione Wi-Fi
Basso
  • Esecuzione di codice arbitrario locale in un contesto vincolato
  • Vulnerabilità crittografica nell'utilizzo non standard
  • Un bypass generale per una difesa approfondita a livello dell'utente o per sfruttare la tecnologia di mitigazione in un contesto non privilegiato
  • Documentazione errata che può portare a un malinteso relativo alla sicurezza con conseguenti difetti del codice
  • By-pass generale di personalizzazione on-device caratteristiche come Voice partita o Viso Partita
Impatto trascurabile sulla sicurezza (NSI)
  • Una vulnerabilità il cui impatto è stato attenuato 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 persistere
  • Ogni vulnerabilità che richiede un filesystem malformati, se questo file system è sempre adottata / crittografata 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 -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 da quando è stato acceso -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 modalità sviluppatore stessa). Non superiore a Basso
Se nessun dominio SELinux può eseguire l'operazione sotto la 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 su 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.

Attacchi locali richiedono la vittima per eseguire un app, sia per l'installazione e l'esecuzione di un'applicazione o acconsentendo di eseguire un immediato App . Ai fini delle valutazioni di gravità, consideriamo 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. Tieni presente che gli attacchi che richiedono una connessione USB hanno la stessa gravità indipendentemente dal fatto che il dispositivo debba essere sbloccato o meno; è normale che i dispositivi vengano sbloccati mentre sono collegati a USB.

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 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 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 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 è uno spazio stimolante, e anche i migliori sistemi può essere ingannato da un quasi-partita (vedi Sviluppatori Android Blog: Lockscreen e autenticazione miglioramenti in Android 11 ). Questi livelli di 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 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 concede l'accesso al dispositivo in base ai residui lasciati sul sensore, è un semplice attacco che potrebbe essere eseguito su qualsiasi dispositivo suscettibile. 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 generalmente coinvolge 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 riceverà il punteggio di gravità completo). Ma se un utente malintenzionato avesse bisogno di acquisire dati biometrici direttamente dal proprietario del dispositivo (ad esempio, una scansione a infrarossi del suo 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 in materia di SYSTEM_ALERT_WINDOW e tapjacking, vedere la "/ sovrapposizione SYSTEM_ALERT_WINDOW vulnerabilità Tapjacking su uno schermo non critici per la sicurezza" di di BugHunter Università Bugs senza alcun impatto di sicurezza pagina.

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 alcuni componenti o bug che sono già noti pubblicamente possono essere corretti direttamente nel ramo principale AOSP pubblicamente disponibile; altrimenti vengono riparati 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 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 di sicurezza Android, informeremo i partner Android dei dettagli del problema e forniremo 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 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.

Ricezione di 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 dal corriere 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 (TA) dell'operatore. Google pubblica anche le immagini Pixel di fabbrica che possono essere lato caricato a 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 applicazioni installate al di fuori di Google Play, i dispositivi con Google Play Services possono anche utilizzare la verifica delle app funzione per mettere in guardia gli utenti sulle applicazioni che possono essere potenzialmente dannosi.

Altre risorse

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

Le informazioni sulla sicurezza sono presenti in tutti i siti Android Open Source e Developer. Buoni punti di partenza:

Rapporti

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