Android Oreos tilbakerullingsbeskyttelse kreves på telefoner som lanseres med Android Pie

Android Pie (Android 9) gikk akkurat live i dag for Google Pixel, Google Pixel 2 og tilogmed Viktig telefon. Vi lærer så mye vi kan om utgivelsen fra intervjuer (Google Pixel 3 vil bare ha bevegelsesnavigering!), den AOSP-kodefall, og til slutt Compatibility Definition Document (CDD). Vi postet om en ny funksjon for "tunge" apper tidligere i dag, men nå har vi funnet ut at Google har endret ordlyden på en funksjon introdusert i Android Oreo: tilbakerullingsbeskyttelse. Funksjonen er gjort mulig av Android Verified Boot 2.0 (også bare kjent som Verified Boot), men OEM-er var ikke pålagt å implementere AVB 2.0 i Oreo-utgivelsen. Nå krever Google at alle enheter som lanseres med Android Pie støtter Verified Boot, og i forlengelsen tilbakerullingsbeskyttelse.

Tilbakestillingsbeskyttelse i Android Oreo

Hovedpoenget med funksjonen er at det vil forhindre at telefonen starter opp hvis den oppdager at enheten ble nedgradert til en tidligere, nå ikke-godkjent versjon av programvare som har blitt ansett som usikker på grunn av en sikkerhet sårbarhet. En litt mer teknisk forklaring er at VBMeta-datastrukturen, som inneholder hashen for oppstartspartisjonen og hashtree-metadata for system- og leverandørpartisjoner, bruker en tilbakestillingsindeks for å avvise bilder som har en eldre tilbakeføring indeks.

Denne funksjonen er til stede på enheter som Google Pixel 2, Razer Phone og OnePlus 6, men er ikke til stede på mange andre enheter som Samsung Galaxy S9 (selv om Samsung tilbyr sin egen form for tilbakerullingsbeskyttelse i Knox.) Nå gjør Google funksjonen obligatorisk for alle enheter som lanseres med Android Pie.

Verifisert oppstart i Android Pie

I henhold til den oppdaterte ordlyden i delen "Enhetsintegritet" i kompatibilitetsdefinisjonsdokumentet, må enheter som starter med Android 9 støtte Verified Boot.

9.10. Enhetsintegritet

Følgende krav sikrer at det er åpenhet om statusen til enhetens integritet. Enhetsimplementeringer:

• [C-0-1] MÅ rapportere korrekt gjennom System API-metoden PersistentDataBlockManager.getFlashLockState() om deres oppstartslastertilstand tillater blinking av systembildet. FLASH_LOCK_UNKNOWN-tilstanden er reservert for enhetsimplementeringer som oppgraderes fra en tidligere versjon av Android der denne nye system-API-metoden ikke fantes.
• [C-0-2] MÅ støtte Verified Boot for enhetsintegritet.

Hvis enhetsimplementeringer allerede er lansert uten å støtte Verified Boot på en tidligere versjon av Android og kan ikke legge til støtte for denne funksjonen med en systemprogramvareoppdatering, KAN de bli unntatt fra krav.

...

• [C-1-10] MÅ implementere tilbakerullingsbeskyttelse for partisjoner som brukes av Android (f.eks. oppstart, systempartisjoner) og bruk manipulasjonssikker lagring for å lagre metadataene som brukes for å bestemme minimum tillatt OS versjon.
• BØR implementere tilbakerullingsbeskyttelse for enhver komponent med vedvarende fastvare (f.eks. modem, kamera) og BØR bruke manipulasjonssikker lagring for å lagre metadataene som brukes for å bestemme minimum tillatt versjon.

Som du kan se i de to siste settene med kulepunkter, er det ett forbehold å merke seg. Tilbakestillingsbeskyttelse er nødvendig for partisjoner som brukes av Android (oppstart, system, leverandør, etc.), men ikke for partisjoner med vedvarende fastvare (modem, kamera, etc.). Det tidligere settet med partisjoner er der de fleste sikkerhetssårbarhetene blir oppdaget og lappet, så det er hyggelig å se at beskyttelse av disse partisjonene er påbudt. Imidlertid har det vært utnyttelser som også retter seg mot partisjoner med vedvarende fastvare, så vi er usikre på hvorfor Google ikke krever tilbakeføringsbeskyttelse på dem.

XDA seniormedlem npjohnson, et medlem av LineageOS-teamet, spekulerer i at det å kreve tilbakerullingsbeskyttelse på partisjoner med vedvarende fastvare krever Secondary Bootloader (SBL) og eXtensible Bootloader (XBL) tie-ins siden disse partisjonene er montert tidligere i oppstarten prosess. Det ville være kostbart for mindre OEM-er å implementere tilpassede XBL-er for å matche de tilpassede modemene og andre vedvarende partisjoner, så kanskje Google ikke gjør dette til et krav for å gjøre det enklere for enhetsprodusenter å oppfylle de nyeste kravene i CDD.

Hvordan sjekke om telefonen støtter AVB 2.0

Det er to ADB-skallkommandoer du kan bruke for å sjekke om telefonen din støtter AVB 2.0.

adb shell
dumpsys package | grep "verified_boot"

ELLER

adb shell
getprop | grep "avb"

Hvis utdata fra den første kommandoen er "android.software.verified_boot", så støttes AVB 2.0. Hvis utdataene fra den andre kommandoen viser "[ro.boot.avb_version]" og "[ro.boot.vbmeta.avb_version]" og viser et versjonsnummer for hver, så støttes det.

Verifisert oppstart og tilpasset utvikling

Android Verified Boot påvirker egentlig ikke de fleste tilpassede ROM-brukere, selv om det legger til et ekstra lag med sikkerhet du må omgå i noen tilfeller. For eksempel, blinker et generisk systembilde krever deaktivering av AVB. Å endre visse partisjoner som leverandøren på OnePlus 6 krever også å deaktivere AVB, som jeg nylig har lært. I følge npjohnson, riktig implementert AVB 2.0 gjør det mulig for egendefinerte oppstartsbilder å fungere med en låst oppstartslaster. Vi skal se hvordan inkluderingen av AVB 2.0 på enheter som sendes med Android Pie påvirker landskapet, men vi håper det ikke resulterer i situasjoner som nylig mursteinsskrekk i Xiaomi Redmi Note 5 Pro-fellesskapet. Obligatorisk AVB 2.0 er bare en annen måte for Google å gjøre det på forbedre Android-plattformsikkerheten, men den største endringen, etter vårt syn, er omarbeiding av OEM-avtaler for å kreve regelmessige sikkerhetsoppdateringer.