Zaštita od vraćanja Androida Oreo potrebna je na telefonima koji se pokreću s Androidom Pie

Android Pie (Android 9) upravo je danas krenuo uživo za Google Pixel, Google Pixel 2 i čak i Osnovni telefon. Učimo koliko god možemo o izdanju iz intervjua (Google Pixel 3 imat će samo navigaciju gestama!), the Ispuštanje AOSP koda, i na kraju Dokument o definiciji kompatibilnosti (CDD). Objavili smo o a nova značajka za "teške" aplikacije ranije danas, ali sada smo otkrili da je Google promijenio svoj tekst o značajci predstavljenoj u Androidu Oreo: zaštita od vraćanja. Značajku je omogućio Android Verified Boot 2.0 (također poznato jednostavno kao Verified Boot), međutim, proizvođači originalne opreme nisu morali implementirati AVB 2.0 u izdanju Oreo. Sada Google nalaže da svi uređaji koji se pokreću s Androidom Pie podržavaju Verified Boot, a time i zaštitu od vraćanja.

Zaštita od vraćanja u Android Oreo

Bit značajke je da će spriječiti pokretanje vašeg telefona ako otkrije da je uređaj vraćen na stariju verziju na raniju, sada neodobrenu verziju softvera koja se smatra nesigurnom zbog sigurnosti ranjivost. Malo više tehničko objašnjenje je da struktura podataka VBMeta, koja sadrži hash za boot particiju i hashtree metapodaci za particije sustava i dobavljača, koristi indeks povrata za odbijanje slika koje imaju starije vraćanje indeks.

Ova je značajka prisutna na uređajima kao što su Google Pixel 2, Razer Phone i OnePlus 6, ali nije prisutna na mnogim drugim uređajima poput Samsung Galaxy S9 (iako Samsung nudi vlastiti oblik zaštita od vraćanja u Knox.) Google sada ovu značajku čini obaveznom za sve uređaje koji se pokreću s Androidom Pie.

Potvrđeno pokretanje u Android Pie

Prema ažuriranom tekstu u odjeljku "Cjelovitost uređaja" u dokumentu o definiciji kompatibilnosti, uređaji koji se pokreću s Androidom 9 moraju podržavati Verified Boot.

9.10. Integritet uređaja

Sljedeći zahtjevi osiguravaju transparentnost statusa integriteta uređaja. Implementacije uređaja:

• [C-0-1] MORA ispravno prijaviti kroz System API metodu PersistentDataBlockManager.getFlashLockState() dopušta li njihovo stanje pokretačkog programa bljeskanje slike sustava. Stanje FLASH_LOCK_UNKNOWN rezervirano je za implementacije uređaja koje se nadograđuju s ranije verzije Androida gdje ova nova API metoda sustava nije postojala.
• [C-0-2] MORA podržavati Verified Boot za integritet uređaja.

Ako su implementacije uređaja već pokrenute bez podrške za Verified Boot na ranijoj verziji Androida i ne mogu dodati podršku za ovu značajku s ažuriranjem softvera sustava, MOGU biti izuzeti iz zahtjev.

...

• [C-1-10] MORA implementirati zaštitu od vraćanja za particije koje koristi Android (npr. pokretanje, sistemske particije) i koristiti pohranu zaštićenu od neovlaštenog otvaranja za pohranu metapodataka koji se koriste za određivanje minimalnog dopuštenog OS-a verzija.
• TREBALI bi implementirati zaštitu od povrata za bilo koju komponentu s postojanim firmware-om (npr. modem, kamera) i TREBA koristiti pohranu zaštićenu od neovlaštenog otvaranja za pohranjivanje metapodataka koji se koriste za određivanje minimalno dopuštenog verzija.

Kao što možete vidjeti u posljednja dva niza točaka, postoji jedno upozorenje koje treba imati na umu. Zaštita od vraćanja potrebna je za particije koje koristi Android (pokretanje, sustav, dobavljač itd.), ali ne i za particije s postojanim firmverom (modem, kamera itd.). Prethodni skup particija mjesto je gdje se otkriva i zakrpa većina sigurnosnih propusta pa je lijepo vidjeti da je zaštita tih particija obavezna. Međutim, bilo je eksploatacija koje ciljaju i na particije s postojanim firmwareom pa nismo sigurni zašto Google na njima ne zahtijeva zaštitu od vraćanja.

Stariji član XDA npjohnson, član LineageOS tima, nagađa da bi zahtijevanje zaštite od vraćanja na particije s postojanim firmwareom zahtijevaju veze sekundarnog pokretača (SBL) i eXtensible pokretača (XBL) budući da su ove particije montirane ranije u pokretanju postupak. Za manje OEM proizvođače bilo bi skupo implementirati prilagođene XBL-ove koji bi odgovarali prilagođenim modemima i drugim trajnim particijama, pa možda Google ovo ne postavlja kao uvjet kako bi proizvođačima uređaja olakšao ispunjavanje najnovijih zahtjeva u CDD-u.

Kako provjeriti podržava li vaš telefon AVB 2.0

Postoje dvije naredbe ADB ljuske pomoću kojih možete provjeriti podržava li vaš telefon AVB 2.0.

adb shell
dumpsys package | grep "verified_boot"

ILI

adb shell
getprop | grep "avb"

Ako je izlaz prve naredbe "android.software.verified_boot", tada je AVB 2.0 podržan. Ako izlaz druge naredbe prikazuje "[ro.boot.avb_version]" i "[ro.boot.vbmeta.avb_version]" i navodi broj verzije za svaku, tada je podržana.

Potvrđeno pokretanje i prilagođeni razvoj

Android Verified Boot zapravo ne utječe na većinu prilagođenih korisnika ROM-a iako dodaje dodatni sloj sigurnosti koji morate zaobići u nekim slučajevima. Na primjer, treperi generička slika sustava zahtijeva onemogućavanje AVB-a. Promjena određenih particija poput dobavljača na OnePlus 6 također zahtijeva onemogućavanje AVB-a, kako sam nedavno saznao. Prema npjohnson, pravilno implementiran AVB 2.0 omogućuje da prilagođene slike za pokretanje rade sa zaključanim pokretačkim programom. Vidjet ćemo kako će uključivanje AVB 2.0 na uređaje koji se isporučuju s Androidom Pie utjecati na krajolik, ali se nadamo da neće rezultirati situacijama poput recent bricking scare u zajednici Xiaomi Redmi Note 5 Pro. Obvezni AVB 2.0 samo je još jedan način na koji Google može poboljšati sigurnost Android platforme, ali najveća promjena, po našem mišljenju, je prerada OEM sporazuma kako bi se propisale redovite sigurnosne zakrpe.