Zaščita pred povrnitvijo sistema Android Oreo je potrebna na telefonih, ki se zaženejo s sistemom Android Pie

Android Pie (Android 9) ravno danes je šlo v živo za Google Pixel, Google Pixel 2 in celo Osnovni telefon. Iz intervjujev se učimo čim več o izdaji (Google Pixel 3 bo imel samo navigacijo s kretnjami!), the Spustite kodo AOSPin nazadnje dokument z opredelitvijo združljivosti (CDD). Objavili smo o a nova funkcija za "težke" aplikacije prej danes, zdaj pa smo ugotovili, da je Google spremenil svoje besedilo o funkciji, predstavljeni v sistemu Android Oreo: zaščita pred povratkom. Funkcijo omogoča Android Verified Boot 2.0 (znan tudi preprosto kot Verified Boot), vendar proizvajalcem originalne opreme ni bilo treba implementirati AVB 2.0 v izdaji Oreo. Zdaj Google zahteva, da vse naprave, ki se zaženejo z Android Pie, podpirajo preverjen zagon in posledično zaščito pred povrnitvijo.

Zaščita pred povrnitvijo v Android Oreo

Bistvo funkcije je, da prepreči zagon telefona, če zazna, da je bila naprava starejša na prejšnjo, zdaj neodobreno različico programske opreme, ki je bila ocenjena kot nevarna zaradi varnosti ranljivost. Nekoliko bolj tehnična razlaga je, da podatkovna struktura VBMeta, ki vsebuje zgoščeno vrednost za zagonsko particijo in metapodatki hashtree za sistemske particije in particije prodajalca, uporablja indeks povrnitve za zavrnitev slik, ki imajo starejšo povrnitev kazalo.

Ta funkcija je prisotna v napravah, kot so Google Pixel 2, Razer Phone in OnePlus 6, vendar ni prisotna v številnih drugih napravah, kot je Samsung Galaxy S9 (čeprav Samsung ponuja svojo lastno obliko zaščita pred povrnitvijo v Knox.) Zdaj je Google naredil obvezno funkcijo za vse naprave, ki se zaženejo s sistemom Android Pie.

Preverjen zagon v Android Pie

V skladu s posodobljenim besedilom v razdelku »Celovitost naprave« v dokumentu z opredelitvijo združljivosti morajo naprave, ki se zaženejo z Androidom 9, podpirati preverjeni zagon.

9.10. Integriteta naprave

Naslednje zahteve zagotavljajo preglednost statusa celovitosti naprave. Izvedbe naprav:

• [C-0-1] MORA prek metode sistemskega API-ja PersistentDataBlockManager.getFlashLockState() pravilno poročati, ali njihovo stanje zagonskega nalagalnika dovoljuje utripanje sistemske slike. Stanje FLASH_LOCK_UNKNOWN je rezervirano za implementacije naprav, ki se nadgrajujejo s prejšnje različice Androida, kjer ta nova metoda sistemskega API-ja ni obstajala.
• [C-0-2] MORA podpirati preverjeni zagon za celovitost naprave.

Če so izvedbe naprav že zagnane brez podpore za preverjen zagon v starejši različici Androida in ne morejo dodati podpore za to funkcijo s posodobitvijo sistemske programske opreme, so LAHKO izvzeti iz zahteva.

...

• [C-1-10] MORA implementirati zaščito pred povrnitvijo za particije, ki jih uporablja Android (npr. zagonske, sistemske particije) in uporabite shranjevanje, ki je zaščiteno pred posegi, za shranjevanje metapodatkov, ki se uporabljajo za določanje najmanjšega dovoljenega OS različica.
• MORALI bi uvesti zaščito pred povrnitvijo za vse komponente s trajno vdelano programsko opremo (npr. modem, kamera) in ZA shranjevanje metapodatkov, ki se uporabljajo za določanje najmanjšega dovoljenega, bi MORALI uporabljati shrambo, ki je zaščitena pred posegi različica.

Kot lahko vidite v zadnjih dveh sklopih točk, je treba upoštevati eno opozorilo. Zaščita pred povrnitvijo je potrebna za particije, ki jih uporablja Android (zagon, sistem, prodajalec itd.), ne pa tudi za particije s trajno vdelano programsko opremo (modem, kamera itd.). Pri prejšnjem nizu particij se odkrije in popravi večina varnostnih ranljivosti, zato je lepo videti, da je zaščita teh particij obvezna. Vendar pa obstajajo izkoriščanja, ki ciljajo tudi na particije s trajno vdelano programsko opremo, zato ne vemo, zakaj Google zanje ne zahteva zaščite pred povrnitvijo.

Starejši član XDA npjohnson, član ekipe LineageOS, domneva, da bi zahteva po zaščiti pred povrnitvijo na particijah s trajno strojno programsko opremo zahtevajo povezave sekundarnega zagonskega nalagalnika (SBL) in razširitvenega zagonskega nalagalnika (XBL), ker so te particije nameščene prej v zagonu postopek. Za manjše proizvajalce originalne opreme bi bilo drago implementirati prilagojene XBL-je, ki bi se ujemali s prilagojenimi modemi in drugimi trajnimi particijami, zato morda Google tega ne zahteva, da bi izdelovalcem naprav olajšal izpolnjevanje najnovejših zahtev CDD.

Kako preveriti, ali vaš telefon podpira AVB 2.0

Obstajata dva ukaza lupine ADB, s katerima lahko preverite, ali vaš telefon podpira AVB 2.0.

adb shell
dumpsys package | grep "verified_boot"

ALI

adb shell
getprop | grep "avb"

Če je rezultat prvega ukaza "android.software.verified_boot", potem je AVB 2.0 podprt. Če izhod drugega ukaza prikazuje "[ro.boot.avb_version]" in "[ro.boot.vbmeta.avb_version]" in navede številko različice za vsakega, potem je podprt.

Preverjen zagon in razvoj po meri

Android Verified Boot v resnici ne vpliva na večino uporabnikov ROM-a po meri, čeprav dodaja dodatno plast varnosti, ki jo morate v nekaterih primerih zaobiti. Na primer, utripanje generične sistemske slike zahteva onemogočanje AVB. Spreminjanje določenih particij, kot je prodajalec na OnePlus 6, zahteva tudi onemogočanje AVB, kot sem pred kratkim izvedel. Po navedbah npjohnson, pravilno implementiran AVB 2.0 omogoča, da zagonske slike po meri delujejo z zaklenjenim zagonskim nalagalnikom. Videli bomo, kako bo vključitev AVB 2.0 v naprave, ki so opremljene s sistemom Android Pie, vplivala na krajino, vendar upamo, da ne bo povzročila situacij, kot je nedavni bricking preplah v skupnosti Xiaomi Redmi Note 5 Pro. Obvezen AVB 2.0 je le še en način za Google izboljšati varnost platforme Android, vendar je po našem mnenju največja sprememba predelava sporazumov OEM, da se zahtevajo redni varnostni popravki.