La protezione rollback di Android Oreo è richiesta sui telefoni avviati con Android Pie

Android Pie (Android 9) è appena andato in diretta oggi per Google Pixel, Google Pixel 2 e persino il Telefono essenziale. Stiamo imparando tutto ciò che possiamo sul rilascio dalle interviste (il Google Pixel 3 avrà solo la navigazione gestuale!), IL Rilascio del codice AOSPe infine il Documento di Definizione della Compatibilità (CDD). Abbiamo pubblicato circa a nuova funzionalità per le app "pesanti". oggi, ma ora abbiamo scoperto che Google ha cambiato la formulazione di una funzionalità introdotta in Android Oreo: protezione antiritorno. La funzionalità è resa possibile da Avvio verificato Android 2.0 (noto anche semplicemente come Verified Boot), tuttavia, agli OEM non era richiesto di implementare AVB 2.0 nella versione Oreo. Ora, Google impone che tutti i dispositivi avviati con Android Pie supportino l'avvio verificato e, per estensione, la protezione dal rollback.

Protezione rollback in Android Oreo

L'essenza della funzionalità è che impedirà l'avvio del telefono se rileva che il dispositivo è stato sottoposto a downgrade a una versione precedente, ora non approvata, del software ritenuta non sicura a causa di una sicurezza vulnerabilità. Una spiegazione leggermente più tecnica è che la struttura dei dati VBMeta, che contiene l'hash per la partizione di avvio e metadati hashtree per partizioni di sistema e fornitore, utilizza un indice di rollback per rifiutare le immagini che hanno un rollback precedente indice.

Questa funzionalità è presente su dispositivi come Google Pixel 2, Razer Phone e OnePlus 6 ma non è presente su molti altri dispositivi come il Samsung Galaxy S9 (sebbene Samsung offra la propria forma di protezione antiritorno in Knox.) Ora, Google sta rendendo la funzionalità obbligatoria per qualsiasi dispositivo che si avvia con Android Pie.

Avvio verificato in Android Pie

Secondo la formulazione aggiornata nella sezione "Integrità del dispositivo" nel documento di definizione della compatibilità, i dispositivi che si avviano con Android 9 devono supportare l'avvio verificato.

9.10. Integrità del dispositivo

I seguenti requisiti garantiscono la trasparenza dello stato di integrità del dispositivo. Implementazioni del dispositivo:

• [C-0-1] DEVE segnalare correttamente tramite il metodo API di sistema PersistentDataBlockManager.getFlashLockState() se lo stato del bootloader consente il flashing dell'immagine di sistema. Lo stato FLASH_LOCK_UNKNOWN è riservato alle implementazioni dei dispositivi che eseguono l'aggiornamento da una versione precedente di Android in cui questo nuovo metodo API di sistema non esisteva.
• [C-0-2] DEVE supportare l'avvio verificato per l'integrità del dispositivo.

Se le implementazioni del dispositivo sono già avviate senza supportare l'avvio verificato su una versione precedente di Android e non è possibile aggiungere il supporto per questa funzionalità con un aggiornamento del software di sistema, POTREBBERO essere esentati da Requisiti.

...

• [C-1-10] DEVE implementare la protezione rollback per le partizioni utilizzate da Android (ad esempio avvio, partizioni di sistema) e utilizzare sistemi di archiviazione a prova di manomissione per archiviare i metadati utilizzati per determinare il sistema operativo minimo consentito versione.
• DOVREBBE implementare la protezione rollback per qualsiasi componente con firmware persistente (ad esempio modem, fotocamera) e DOVREBBE utilizzare un sistema di archiviazione a prova di manomissione per archiviare i metadati utilizzati per determinare il minimo consentito versione.

Come puoi vedere negli ultimi due punti elenco, c'è un avvertimento da notare. La protezione rollback è necessaria per le partizioni utilizzate da Android (avvio, sistema, fornitore, ecc.) ma non per le partizioni con firmware persistente (modem, fotocamera, ecc.). Il primo set di partizioni è il luogo in cui vengono scoperte e risolte la maggior parte delle vulnerabilità della sicurezza, quindi è bello vedere che la protezione di queste partizioni è obbligatoria. Tuttavia, ci sono stati exploit che prendono di mira anche partizioni con firmware persistente, quindi non siamo sicuri del motivo per cui Google non imponga loro la protezione rollback.

Membro senior dell'XDA npjohnson, un membro del team LineageOS, ipotizza che la richiesta di protezione rollback su partizioni con firmware persistente lo farebbe richiedono collegamenti con il Bootloader secondario (SBL) e l'eXtensible Bootloader (XBL) poiché queste partizioni vengono montate prima nell'avvio processi. Sarebbe costoso per gli OEM più piccoli implementare XBL personalizzati per abbinare i modem personalizzati e altre partizioni persistenti, quindi forse Google non lo sta rendendo un requisito per rendere più semplice per i produttori di dispositivi soddisfare i requisiti più recenti della CDD.

Come verificare se il tuo telefono supporta AVB 2.0

Esistono due comandi shell ADB che puoi utilizzare per verificare se il tuo telefono supporta AVB 2.0.

adb shell
dumpsys package | grep "verified_boot"

O

adb shell
getprop | grep "avb"

Se l'output del primo comando è "android.software.verified_boot", è supportato AVB 2.0. Se l'output del secondo comando mostra "[ro.boot.avb_version]" e "[ro.boot.vbmeta.avb_version]" ed elenca un numero di versione per ciascuno, allora è supportato.

Avvio verificato e sviluppo personalizzato

L'avvio verificato di Android non influisce in realtà sulla maggior parte degli utenti di ROM personalizzate, anche se aggiunge un ulteriore livello di sicurezza che in alcuni casi è necessario aggirare. Ad esempio, lampeggiare un'immagine di sistema generica richiede la disabilitazione di AVB. La modifica di alcune partizioni come quella del fornitore su OnePlus 6 richiede anche la disabilitazione di AVB, come ho appreso di recente. Secondo npjohnson, AVB 2.0 correttamente implementato consente alle immagini di avvio personalizzate di funzionare con un bootloader bloccato. Vedremo come l'inclusione di AVB 2.0 sui dispositivi forniti con Android Pie influisce sul panorama, ma speriamo che non si traduca in situazioni come quella recente spavento di mattoni nella comunità Xiaomi Redmi Note 5 Pro. L'AVB 2.0 obbligatorio è solo un altro modo per Google di farlo migliorare la sicurezza della piattaforma Android, ma il cambiamento più grande, a nostro avviso, è il rielaborazione degli accordi OEM per imporre patch di sicurezza regolari.