Aggiornamenti e risorse per la sicurezza

Il team di sicurezza di Android è responsabile della gestione delle vulnerabilità di sicurezza rilevate in la piattaforma Android e molte delle principali app per Android in bundle con i dispositivi Android.

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

Segnalazione di problemi di sicurezza

Qualsiasi sviluppatore, utente Android o ricercatore in materia di sicurezza può informare il team addetto alla sicurezza di Android potenziali problemi di sicurezza modulo di vulnerabilità.

I bug contrassegnati come problemi di sicurezza non sono visibili all'esterno, ma potrebbero essere segnalati. visibili dopo che il problema è stato valutato o risolto. Se prevedi di inviare una patch o test della Compatibility Test Suite (CTS) per risolvere un problema di sicurezza, allegalo al bug e attendi una risposta prima di caricare il codice su AOSP.

Valutazione degli insetti

La prima attività 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 correggi il bug, chi riceve una notifica e come viene implementata la correzione agli utenti.

Tipi di contesto

Questa tabella illustra le definizioni dei contesti di sicurezza hardware e software. Il contesto può definita dalla sensibilità dei dati che generalmente elabora o dall'area in cui vengono eseguiti. No tutti i contesti di sicurezza sono applicabili a tutti i sistemi. Questa tabella è ordinata dal meno al più alto privilegiato.

Tipo di contesto Definizione del tipo
Contesto vincolato Un ambiente di esecuzione limitato in cui viene utilizzata la quantità minima di autorizzazioni fornito.

Ad esempio, applicazioni attendibili che elaborano dati non attendibili all'interno di un ambiente completamente gestito di Google Cloud.
Contesto senza privilegi Un ambiente di esecuzione tipico previsto da codice senza privilegi.

Ad esempio, un'applicazione Android eseguita in un dominio SELinux con Attributo untrusted_app_all.
Contesto con privilegi Un ambiente di esecuzione con privilegi che può avere accesso ad autorizzazioni elevate, gestisce PII di più utenti e/o mantiene l'integrità del sistema.

Ad esempio, un'app per Android con funzionalità vietate dal SELinux untrusted_app o con accesso a 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, ai componenti hardware sul dispositivo)
  • ha la capacità di caricare script in un componente kernel (ad esempio, eBPF)
  • è uno dei tanti servizi utente considerati equivalenti al kernel (come, apexd, bpfloader, init e ueventd e vold).
Base hardware attendibile (THB) Componenti hardware discreti, in genere sul SoC, che forniscono funzionalità critiche ai casi d'uso principali del dispositivo (ad esempio, bande di base cellulari, DSP, GPU e processori).
Catena per bootloader Un componente che configura il dispositivo all'avvio e poi passa il controllo al sistema operativo Android.
Ambiente di esecuzione affidabile (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 sistema operativo ).
Secure Enclave / Secure Element (SE) Un componente hardware facoltativo progettato per essere protetto da tutti gli altri componenti del dispositivo e da un attacco fisico, come definito Introduzione a Secure Elements.

Questo 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 sfruttata con successo. Utilizzare i seguenti criteri per determinare la gravità.

Classificazione Conseguenza di uno sfruttamento riuscito
Critica
  • Esecuzione arbitraria di codice in TEE o SE
  • Elusione di meccanismi software progettati per prevenire software o hardware relativi alla sicurezza il malfunzionamento dei componenti (ad esempio le protezioni termiche)
  • Accesso remoto alle credenziali sensibili utilizzate per l'autenticazione del servizio remoto (ad ad esempio password di account o token di connessione)
  • Esecuzione di codice arbitrario remoto all'interno del contesto della banda di base cellulare senza utente Interazione (ad esempio, sfruttamento di un bug nel servizio radio cellulare)
  • Esecuzione di codice arbitrario remoto in un contesto con privilegi, nella catena di bootloader, in THB il kernel del sistema operativo
  • Bypass da remoto dei requisiti di interazione dell'utente durante l'installazione del pacchetto o un equivalente comportamento
  • Bypass da remoto dei requisiti di interazione dell'utente per sviluppatori di base, sicurezza impostazioni privacy
  • denial of service permanente da remoto (permanente, che richiede l'aggiornamento dell'intero un sistema operativo o un ripristino dei dati di fabbrica)
  • Bypass dell'avvio protetto da remoto
  • Accesso non autorizzato ai dati protetti da SE, incluso l'accesso abilitato da chiavi inefficaci la SE.
Alto
  • Un bypass completo di una funzionalità di sicurezza di base (ad esempio, SELinux, FBE o seccomp
  • Un bypass generale per una difesa approfondita o una tecnologia di mitigazione degli exploit nel catena di bootloader, TEE o SE
  • Un bypass generale per le protezioni del sistema operativo che rivelano i contenuti di memoria o file oltre i confini dell'app, dell'utente o del profilo
  • Attacchi contro una SE che comportano il downgrade a un'implementazione meno sicura
  • Pivot da un firmware bare-metal compromesso raggiungibile da remoto (ad es. baseband, CP/processore di comunicazione) nel kernel del processore di applicazione (AP) o ignorare meccanismi progettati per isolare il firmware bare-metal dal kernel AP
  • Bypass della protezione del dispositivo/ripristino dei dati di fabbrica/limitazioni dell'operatore
  • Bypass dei requisiti di interazione dell'utente garantiti dal TEE
  • Vulnerabilità crittografica che consente attacchi contro i protocolli end-to-end, inclusi gli attacchi contro il protocollo TLS (Transport Layer Security) e Bluetooth (BT).
  • Accesso locale alle credenziali sensibili utilizzate per l'autenticazione del servizio remoto (ad ad esempio password di account o token di connessione)
  • Esecuzione di codice arbitrario locale in un contesto con privilegi, nella catena di bootloader, in THB il kernel del sistema operativo
  • Bypass dell'avvio protetto locale
  • Bypass della schermata di blocco
  • Aggiramento locale dei requisiti di interazione dell'utente per sviluppatore di base, sicurezza o privacy impostazioni
  • Aggiramento locale dei requisiti di interazione dell'utente durante l'installazione del pacchetto o un equivalente comportamento
  • denial of service locale persistente (permanente, che richiede l'aggiornamento dell'intero sistema operativo o ripristinare i dati di fabbrica)
  • Accesso remoto ai dati protetti (ovvero, dati limitati a un contesto)
  • Esecuzione di codice arbitrario remoto in un contesto senza privilegi
  • Prevenzione da remoto dell'accesso a un servizio cellulare o Wi-Fi senza interazione dell'utente (ad esempio, l'arresto anomalo del servizio radio cellulare con un pacchetto in formato non corretto)
  • aggiramento da remoto dei requisiti di interazione dell'utente (accesso a funzionalità o dati che deve richiedere l'avvio o l'autorizzazione dell'utente).
  • Prevenzione mirata dell’accesso ai servizi di emergenza
  • La 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. Nota Non si applica alla crittografia Wi-Fi (ad esempio WEP)
  • Accesso non autorizzato ai dati protetti dal TEE, incluso l'accesso abilitato da chiavi inefficaci nel TEE
Moderato
  • Un bypass generale per una difesa in profondità o sfruttare la tecnologia di mitigazione in un contesto con privilegi, THB o kernel del sistema operativo
  • Un bypass generale per le protezioni del sistema operativo che rivela lo stato del processo o metadati al di fuori dei confini dell'app, dell'utente o del profilo
  • Bypass della crittografia o dell'autenticazione Wi-Fi
  • Vulnerabilità crittografica nelle primitive di crittografia standard che consente la fuga di testo non crittografato (non primitive utilizzate in TLS)
  • Accesso locale ai dati protetti (ovvero, dati limitati a un contesto con privilegi)
  • Esecuzione di codice arbitrario locale in un contesto senza privilegi
  • Aggiramento locale dei requisiti di interazione dell'utente (accesso a funzionalità o dati che richiede normalmente l'avvio o l'autorizzazione dell'utente).
  • Accesso remoto ai dati non protetti (ossia ai dati normalmente accessibili a qualsiasi app installata)
  • Esecuzione di codice arbitrario remoto in un contesto vincolato
  • denial of service temporaneo remoto del dispositivo (blocco o riavvio da remoto)
Bassa
  • Un bypass generale per una difesa a livello di utente in profondità o una tecnologia di mitigazione degli exploit in un contesto senza privilegi
  • Bypass di una normale livello di protezione autorizzazione
  • Vulnerabilità crittografica nell'uso non standard
  • Bypass generale delle funzionalità di personalizzazione sul dispositivo, ad esempio Voice Match o Face Match
  • Documentazione errata che potrebbe causare una vulnerabilità di sicurezza
  • Esecuzione di codice arbitrario locale in un contesto vincolato
  • Testo definito dal sistema che include una descrizione fuorviante che crea un falso aspettativa di sicurezza
Impatto trascurabile sulla sicurezza (NSI)
  • Una vulnerabilità il cui impatto è stato mitigato da uno o più modificatori di classificazione o specifiche della versione in modo tale che la gravità effettiva sia inferiore a Bassa, anche se il problema di codice sottostante può rimanere
  • Qualsiasi vulnerabilità che richiede un file system in formato non corretto, se tale file system è sempre adottati/criptati prima dell'uso.
  • denial of service temporaneo locale, ad esempio se la condizione può essere risolta riavviando il dispositivo o disinstallando l'app di attivazione.

Modificatori di valutazione

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

Motivo Effetto
Richiede l'esecuzione come contesto con privilegi per l'esecuzione dell'attacco (non applicabile a TEE, SE, e hypervisor 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 ai componenti interni del dispositivo ed è comunque possibile se il dispositivo è spento o non è stato sbloccato da quando è stato acceso - Gravità 1
Richiede l'accesso fisico ai componenti interni del dispositivo quando questo è acceso e in precedenza sbloccato -2 Gravità
Un attacco locale che richiede lo sblocco della catena del bootloader Non superiore a Basso
Un attacco locale che richiede la Modalità sviluppatore o qualsiasi impostazione permanente della modalità sviluppatore per sia attiva sul dispositivo (e non è un bug nella modalità sviluppatore). Non superiore a Basso
Se nessun dominio SELinux può eseguire l'operazione secondo il SEPolicy fornito da Google Impatto sulla sicurezza trascurabile

Locale, prossimale 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 un leggere una pagina web, leggere email, ricevere SMS o connettersi a una rete ostile.

I vettori di attacco prossimali sono considerati remoti. Includono bug che possono essere sfruttati solo da un aggressore che si trova fisicamente vicino al dispositivo bersaglio, ad esempio un bug che richiede invio di pacchetti Wi-Fi o Bluetooth non corretti. Prendiamo in considerazione la banda ultralarga (UWB) e basata su NFC degli attacchi come prossimali e quindi remoti.

Gli attacchi locali richiedono all'aggressore di avere prima accesso alla vittima. In un'ottica ipotetica esempio solo software, ad esempio tramite un'app dannosa installata dalla vittima, o un App istantanea di cui dispongono acconsentito alla pubblicazione.

I dispositivi accoppiati correttamente (come i dispositivi Bluetooth associati) sono considerati locali. Me fare una distinzione tra un dispositivo accoppiato e un dispositivo che sta partecipando a un accoppiamento flusso di lavoro.

  • Bug che riducono la capacità dell'utente di identificare l'altro dispositivo accoppiato (ad esempio, autenticazione) sono considerati prossimali e quindi remoti.
  • I bug che si verificano durante il flusso di accoppiamento, ma prima del consenso dell'utente (ad es. l'autorizzazione), hanno 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 non riesce.

I vettori di attacco fisico sono considerati locali. Includono i bug che possono essere sfruttati solo un malintenzionato che ha accesso fisico al dispositivo, ad esempio un bug in una schermata di blocco o che richiede il collegamento di un cavo USB. Poiché è comune che i dispositivi vengano sbloccati durante collegato a una porta USB, gli attacchi che richiedono una connessione USB hanno la stessa gravità indipendentemente se il dispositivo deve essere sbloccato o meno.

Sicurezza della rete

Android presuppone che tutte le reti siano ostili e potrebbero iniettare attacchi o spiare per via del traffico. Mentre la sicurezza a livello di link (ad esempio la crittografia Wi-Fi) protegge le comunicazioni tra un dispositivo e il punto di accesso a cui è connesso, non fa nulla per proteggere gli altri collegamenti della catena tra il dispositivo e i server con cui comunica.

Al contrario, HTTPS protegge l'intera comunicazione end-to-end, criptando i dati all'origine, per poi decriptarlo e verificarlo solo dopo aver raggiunto la destinazione finale. Per questo motivo, le vulnerabilità che compromettono la sicurezza di rete a livello di collegamento sono valutate meno. molto gravi delle vulnerabilità di HTTPS/TLS: la sola crittografia Wi-Fi non è sufficiente per la maggior parte la comunicazione su internet.

Autenticazione biometrica

L'autenticazione biometrica è un settore difficile e persino i sistemi migliori possono essere ingannati da un quasi (vedi Blog per sviluppatori Android: miglioramenti della schermata di blocco e dell'autenticazione in Android 11. Questi livelli di gravità fanno distinzione tra due classi di attacchi e hanno lo scopo di riflettono 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 utente malintenzionato può inserire un pezzo di gomma su un sensore di impronte digitali e concede l'accesso al dispositivo in base ai residui rimasti al sensore, un semplice attacco che può essere eseguito su qualsiasi dispositivo suscettibile. it non richiede alcuna conoscenza del proprietario del dispositivo. Dato che è generalizzabile ha un potenziale impatto su un maggior numero di utenti, questo attacco riceve la massima gravità (ad esempio, Alta, per un'esclusione della schermata di blocco).

L’altra classe di attacchi prevede generalmente uno strumento di attacco basato su presentazione (spoofing) del proprietario del dispositivo. A volte è relativamente facile ottenere queste informazioni biometriche (ad Ad esempio, se l'immagine del profilo di una persona sui social media è sufficiente a ingannare l'autenticazione biometrica, quindi un bypass biometrico riceverebbe la valutazione di gravità completa). Ma se un aggressore ha bisogno per acquisire dati biometrici direttamente dal proprietario del dispositivo (ad esempio, una scansione a infrarossi di il loro volto), si tratta di una barriera talmente significativa da limitare il numero di persone colpite dall'attacco, quindi c'è un modificatore -1.

SYSTEM_ALERT_WINDOW e Tapjacking

Per informazioni sulle nostre norme relative a SYSTEM_ALERT_WINDOW e tapjacking, controlla la "vulnerabilità Tapjacking/overlay SYSTEM_ALERT_WINDOWS in una schermata non critica per la sicurezza" della BugHunter University Bug senza impatto sulla sicurezza .

Sicurezza multiutente nel sistema operativo Android Automotive

Android Automotive OS adotta un modello di sicurezza multiutente dagli altri fattori di forma. Ogni utente Android deve essere utilizzato da un persona fisica. Ad esempio, un utente ospite temporaneo può essere assegnato a un amico che prende in prestito dal proprietario dell'auto. Per rispondere a casi d'uso come questo, gli utenti hanno per impostazione predefinita Accesso ai componenti necessari all'utilizzo del veicolo, ad esempio Wi-Fi e rete mobile impostazioni.

Componente interessato

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

I bug nel codice AOSP vengono corretti dal team tecnico di Android. Bug a bassa gravità, bug in alcuni componenti o bug già noti pubblicamente possono essere corretti direttamente ramo principale AOSP disponibile pubblicamente; altrimenti vengono corretti nei repository interni per prima cosa.

Il componente incide anche sul modo in cui gli utenti ricevono gli aggiornamenti. Un bug nel framework o nel kernel richiede un aggiornamento firmware over-the-air (OTA) che ogni OEM deve inviare. Un bug in un'app o libreria pubblicata in Google Play (ad esempio, Gmail, Google Play Services o WebView) può essere inviati agli utenti Android come aggiornamento da Google Play.

Invio notifica ai partner

Quando in un Bollettino sulla sicurezza di Android viene corretta una vulnerabilità di sicurezza in AOSP, inviamo una notifica I partner Android forniscono dettagli sui problemi e patch. L'elenco delle versioni supportate dal backport a ogni nuova release di Android. Contatta il produttore del tuo dispositivo per ricevere l'elenco di sui dispositivi supportati.

Rilascio del codice in AOSP

Se il bug di sicurezza si trova in un componente AOSP, la correzione viene inviata ad AOSP dopo l'invio dell'aggiornamento OTA rilasciate agli utenti. Le correzioni per i problemi di bassa gravità possono essere inviate direttamente all'AOSP principale prima che sia disponibile una correzione per i dispositivi tramite un'OTA.

Ricezione di aggiornamenti Android

In genere, gli aggiornamenti del sistema Android vengono forniti ai dispositivi tramite pacchetti di aggiornamento OTA. Questi aggiornamenti possono provenire dall'OEM che ha prodotto il dispositivo o dall'operatore che fornisce servizio al dispositivo. Gli aggiornamenti dei dispositivi Google Pixel arrivano dal team di Google Pixel attraverso una procedura di test di accettazione tecnica (TA) dell'operatore. Google pubblica anche immagini del produttore Pixel che possono essere manualmente sui dispositivi.

Aggiornamento dei servizi Google

Oltre a fornire patch per i bug di sicurezza, il team di sicurezza di Android esamina per stabilire se esistono altri modi per proteggere gli utenti. Ad esempio, Google Play analizza tutti app e rimuove tutte le app che tentano di sfruttare un bug di sicurezza. Per le app installate da al di fuori di Google Play, i dispositivi con Google Play Services potrebbero utilizzare anche Funzione Verifica app per visualizzare un avviso agli utenti di app che potrebbero essere potenzialmente dannose.

Altre risorse

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

Le informazioni di sicurezza sono disponibili in tutti i siti per sviluppatori e open source Android. Corretto punti di partenza:

Report

A volte il team addetto alla sicurezza di Android pubblica report o white paper. Consulta: Report sulla sicurezza per ulteriori dettagli.