Secondo un recente impegno che abbiamo scoperto nel progetto Android Open Source, Google si sta preparando per distinguere tra il livello della patch di sicurezza del fornitore e la patch di sicurezza del framework Android livello. Ciò consente agli OEM di mantenere Android aggiornato mentre attendono che i fornitori di hardware forniscano correzioni.
Per molto tempo, nella sua storia iniziale, Android aveva la reputazione di essere meno sicuro di iOS a causa dell'approccio "walled garden" di Apple alle applicazioni. Se la reputazione passata sia meritata o meno non è qualcosa in cui approfondiremo, ma è chiaro che Google ha fatto grandi passi avanti nel proteggere Android dalle vulnerabilità. L'azienda non solo fornisce nuove funzionalità di sicurezza nell'ultima versione di Android, Androide P, ma stanno anche fornendo "sicurezza di livello aziendale" nei loro ultimi dispositivi grazie a un modulo di sicurezza hardware nel Google Pixel 2/2 XL. Mantenere un dispositivo sicuro richiede anche aggiornamenti continui per applicare patch a tutte le minacce più recenti, motivo per cui Google lo ha fatto
bollettini mensili sulla sicurezza affinché tutti i produttori e i fornitori di dispositivi incorporino patch contro tutte le vulnerabilità attive e potenziali note. Ora, sembra che la società stia apportando modifiche al sistema Android Security Patch fornendo un modo per farlo distinguere tra il livello di patch del framework Android e il livello di patch del fornitore insieme al bootloader, al kernel, ecc. per dividere i livelli di patch di sicurezza in modo che gli OEM possano fornire puri aggiornamenti del framework o identificare meglio all'utente quale livello di patch sta utilizzando.Patch mensili di sicurezza Android: un'introduzione
Sappiamo tutti che le patch di sicurezza sono importanti, soprattutto dopo che una serie di vulnerabilità di alto profilo sono state rese pubbliche nella seconda metà dello scorso anno. IL Vulnerabilità BlueBorne ha attaccato il protocollo Bluetooth ed è stato patchato nel file Patch mensili di settembre 2017, KRACK mira a un punto debole nel Wi-Fi WPA2 ed è stato corretto Dicembre 2017e le vulnerabilità Spectre/Meltdown sono state per lo più risolte con il file Patch di gennaio 2018. L'applicazione di patch a vulnerabilità come queste richiede in genere la collaborazione con un fornitore di hardware (come Broadcom e Qualcomm) perché la vulnerabilità riguarda un componente hardware come il chip Wi-Fi o Bluetooth o l' PROCESSORE. D'altra parte, ci sono problemi nel sistema operativo Android come questo attacco di sovrapposizione di messaggi toast che richiedono solo un aggiornamento del framework Android per essere risolti.
Ogni volta che Google rilascia una patch di sicurezza mensile, i produttori di dispositivi sono tenuti a correggere TUTTE le vulnerabilità indicato nel bollettino sulla sicurezza di quel mese se vogliono affermare che il loro dispositivo è sicuro fino a quella patch mensile livello. Ogni mese, ci sono due livelli di patch di sicurezza che un dispositivo può soddisfare: il livello di patch del 1° del mese o del 5 del mese. Se un dispositivo dice che sta eseguendo un livello di patch dal 1° del mese (es. 1 aprile anziché il 5 aprile), ciò significa che la build contiene tutte le patch del framework E del fornitore dal rilascio del mese scorso più tutte le patch del framework dal bollettino sulla sicurezza più recente. D'altra parte, se un dispositivo dichiara di eseguire un livello di patch a partire dal 5 del mese (5 aprile, per esempio), significa che contiene tutte le patch del framework e del fornitore del mese scorso e di questo mese bollettino. Ecco una tabella che esemplifica la differenza fondamentale tra i livelli di patch mensili:
Livello mensile delle patch di sicurezza |
1 Aprile |
5 aprile |
|---|---|---|
Contiene le patch del framework di aprile |
SÌ |
SÌ |
Contiene le patch del venditore di aprile |
NO |
SÌ |
Contiene le patch del framework di marzo |
SÌ |
SÌ |
Contiene le patch del venditore di marzo |
SÌ |
SÌ |
Probabilmente hai familiarità con quanto sia triste la situazione delle patch di sicurezza nell'ecosistema Android. Il grafico seguente mostra che Google ed Essential forniscono gli aggiornamenti mensili delle patch di sicurezza più rapidi mentre altre società restano indietro. Possono essere necessari mesi prima che un OEM porti le patch più recenti su un dispositivo, come nel caso del OnePlus 5 e OnePlus 5T ha recentemente ricevuto il Patch di sicurezza di aprile quando in precedenza erano sulla patch di dicembre.
Stato della patch di sicurezza Android a febbraio 2018. Fonte: @SezX13
Il problema con la fornitura degli aggiornamenti delle patch di sicurezza Android non è necessariamente che gli OEM siano pigri, poiché a volte la cosa può essere fuori dal loro controllo. Come accennato in precedenza, gli aggiornamenti mensili delle patch di sicurezza spesso richiedono la collaborazione di un hardware fornitore, il che può causare ritardi se il fornitore non è in grado di tenere il passo con la patch di sicurezza mensile bollettini. Per contrastare questo problema, sembra che Google potrebbe iniziare a separare il livello delle patch di sicurezza del framework Android dal livello delle patch del fornitore (e possibilmente il bootloader e il livello del kernel) in modo che in futuro gli OEM possano essere in grado di fornire sicurezza puramente del framework Android aggiornamenti.
Aggiornamenti più rapidi delle patch di sicurezza Android per le vulnerabilità del framework?
Un nuovo commettere è apparso nel gerrit del progetto Android Open Source Project (AOSP) che allude a una "patch di sicurezza del fornitore prop" che verrebbe definito nei file Android.mk ogni volta che viene creata una nuova build per un dispositivo creato. Questa struttura si chiamerà "ro.vendor.build.security_patch" e sarà analogo a "ro.build.version.security_patch" che attualmente esiste su tutti i dispositivi Android per specificare il livello mensile delle patch di sicurezza Android.
Questa nuova proprietà ci dirà invece il"VENDOR_SECURITY_PATCH" del dispositivo, che potrebbe corrispondere o meno al livello della patch di sicurezza di Android Framework. Ad esempio, un dispositivo potrebbe essere in esecuzione con le ultime patch del framework di aprile 2018 insieme alle patch del fornitore di febbraio 2018. Distinguendo tra i due livelli di patch di sicurezza, è possibile che Google intenda consentire agli OEM di spedire le patch di sicurezza le ultime patch di sicurezza del sistema operativo Android anche se i fornitori non hanno fornito patch aggiornate per quella patch mensile livello.
In alternativa, Google potrebbe semplicemente visualizzare il minimo dei due livelli di patch (insieme eventualmente ai livelli di patch del bootloader e del kernel) per mostrare in modo più accurato all'utente su quale patch di sicurezza è installato il suo dispositivo. Non abbiamo ancora conferma sull'intento dietro questa patch, ma speriamo di scoprirne di più presto.
Per lo meno, questo sarà utile per quelli di noi Progetto TrebleImmagini di sistema generiche (GSI) e altre ROM personalizzate basate su AOSP poiché spesso le ROM personalizzate forniscono solo aggiornamenti del framework senza applicare patch a tutto il fornitore, bootloader e le patch del kernel specificate in un bollettino mensile sulla sicurezza, quindi la mancata corrispondenza causa confusione tra gli utenti pensano di utilizzare le patch più recenti quando in realtà il loro dispositivo è aggiornato solo parzialmente rispetto all'ultima sicurezza mensile bollettino.