Android Oreos rollback-beskyttelse påkrævet på telefoner, der lanceres med Android Pie

Android Pie (Android 9) gik lige live i dag til Google Pixel, Google Pixel 2 og selv den Vigtig telefon. Vi lærer så meget som muligt om udgivelsen fra interviews (Google Pixel 3 vil kun have gestusnavigation!), det AOSP kode fald, og til sidst kompatibilitetsdefinitionsdokumentet (CDD). Vi skrev om en ny funktion til "heavyweight" apps tidligere i dag, men nu har vi fundet ud af, at Google har ændret deres ordlyd på en funktion introduceret i Android Oreo: tilbagerulningsbeskyttelse. Funktionen er muliggjort af Android Verified Boot 2.0 (også blot kendt som Verified Boot), men OEM'er var ikke forpligtet til at implementere AVB 2.0 i Oreo-udgivelsen. Nu kræver Google, at alle enheder, der lanceres med Android Pie, understøtter Verified Boot, og i forlængelse heraf, rollback-beskyttelse.

Tilbagestillingsbeskyttelse i Android Oreo

Kernen i funktionen er, at den forhindrer din telefon i at starte, hvis den registrerer, at enheden blev nedgraderet til en tidligere, nu ikke-godkendt version af software, der er blevet anset for usikker på grund af en sikkerhed sårbarhed. En lidt mere teknisk forklaring er, at VBMeta-datastrukturen, som indeholder hashen til boot-partitionen og hashtree-metadata for system- og leverandørpartitioner, bruger et rollback-indeks til at afvise billeder, der har en ældre rollback indeks.

Denne funktion er til stede på enheder som Google Pixel 2, Razer Phone og OnePlus 6, men er ikke til stede på mange andre enheder som Samsung Galaxy S9 (selvom Samsung tilbyder deres egen form for tilbagerulningsbeskyttelse i Knox.) Nu gør Google funktionen obligatorisk for enhver enhed, der lanceres med Android Pie.

Verificeret start i Android Pie

Ifølge den opdaterede formulering i afsnittet "Enhedsintegritet" i kompatibilitetsdefinitionsdokumentet skal enheder, der starter med Android 9, understøtte Verified Boot.

9.10. Enhedens integritet

Følgende krav sikrer, at der er gennemsigtighed for status for enhedens integritet. Enhedsimplementeringer:

• [C-0-1] SKAL korrekt rapportere via System API-metoden PersistentDataBlockManager.getFlashLockState(), om deres bootloader-tilstand tillader flashing af systembilledet. FLASH_LOCK_UNKNOWN-tilstanden er reserveret til enhedsimplementeringer, der opgraderer fra en tidligere version af Android, hvor denne nye system-API-metode ikke fandtes.
• [C-0-2] SKAL understøtte Verified Boot for enhedens integritet.

Hvis enhedsimplementeringer allerede er lanceret uden at understøtte Verified Boot på en tidligere version af Android og ikke kan tilføje support til denne funktion med en systemsoftwareopdatering, KAN de blive undtaget fra krav.

...

• [C-1-10] SKAL implementere rollback-beskyttelse for partitioner, der bruges af Android (f.eks. boot, systempartitioner) og brug manipulationssikker lagring til lagring af de metadata, der bruges til at bestemme det mindst tilladte OS version.
• BØR implementere tilbagerulningsbeskyttelse for enhver komponent med vedvarende firmware (f.eks. modem, kamera) og SKAL bruge manipulationssikker lagring til lagring af de metadata, der bruges til at bestemme det tilladte minimum version.

Som du kan se i de sidste to sæt punktopstillinger, er der en advarsel at bemærke. Tilbageføringsbeskyttelse er påkrævet for partitioner, der bruges af Android (boot, system, leverandør osv.), men ikke for partitioner med vedvarende firmware (modem, kamera osv.). Det tidligere sæt af partitioner er, hvor de fleste af sikkerhedssårbarhederne bliver opdaget og rettet, så det er rart at se, at beskyttelse af disse partitioner er påbudt. Der har dog været udnyttelser, der også er målrettet mod partitioner med vedvarende firmware, så vi er usikre på, hvorfor Google ikke kræver tilbagerulningsbeskyttelse på dem.

XDA seniormedlem npjohnson, et medlem af LineageOS-teamet, spekulerer i, at det ville kræve rollback-beskyttelse på partitioner med vedvarende firmware kræver tilknytning til Secondary Bootloader (SBL) og eXtensible Bootloader (XBL), da disse partitioner er monteret tidligere i opstarten behandle. Det ville være dyrt for mindre OEM'er at implementere tilpassede XBL'er for at matche de tilpassede modemer og andre vedvarende partitioner, så måske stiller Google ikke dette til et krav for at gøre det lettere for enhedsproducenter at opfylde de seneste krav i CDD.

Sådan kontrollerer du, om din telefon understøtter AVB 2.0

Der er to ADB-skalkommandoer, du kan bruge til at kontrollere, om din telefon understøtter AVB 2.0.

adb shell
dumpsys package | grep "verified_boot"

ELLER

adb shell
getprop | grep "avb"

Hvis outputtet af den første kommando er "android.software.verified_boot", så understøttes AVB 2.0. Hvis outputtet af den anden kommando viser "[ro.boot.avb_version]" og "[ro.boot.vbmeta.avb_version]" og viser et versionsnummer for hver, så er det understøttet.

Verificeret Boot og Custom Development

Android Verified Boot påvirker ikke rigtig de fleste brugerdefinerede ROM-brugere, selvom det tilføjer et ekstra lag af sikkerhed, du skal omgås i nogle tilfælde. For eksempel, blinker et generisk systembillede kræver, at AVB deaktiveres. Ændring af visse partitioner som leverandør på OnePlus 6 kræver også at deaktivere AVB, som jeg for nylig lærte. Ifølge npjohnson, korrekt implementeret AVB 2.0 gør det muligt for brugerdefinerede bootimages at arbejde med en låst bootloader. Vi vil se, hvordan inkluderingen af ​​AVB 2.0 på enheder, der sendes med Android Pie, påvirker landskabet, men vi håber, at det ikke resulterer i situationer som seneste murstensforskrækkelse i Xiaomi Redmi Note 5 Pro-fællesskabet. Obligatorisk AVB 2.0 er bare en anden måde for Google at gøre det forbedre Android-platformsikkerheden, men den største ændring, efter vores mening, er omarbejdning af OEM-aftaler for at påbyde regelmæssige sikkerhedsrettelser.