U telefonů se systémem Android Pie je vyžadována ochrana proti vrácení systému Android Oreo

Android Pie (Android 9) právě dnes vysílal pro Google Pixel, Google Pixel 2 a dokonce Základní telefon. O vydání se dozvídáme co nejvíce z rozhovorů (Google Pixel 3 bude mít pouze navigaci gesty!), Odpad kódu AOSPa konečně dokument definice kompatibility (CDD). Psali jsme o a nová funkce pro „těžké“ aplikace dnes již dříve, ale nyní jsme zjistili, že Google změnil jejich formulaci u funkce představené v Android Oreo: ochrana proti návratu. Funkce je umožněna tím Android Verified Boot 2.0 (také známý jednoduše jako Verified Boot), nicméně OEM nemuseli implementovat AVB 2.0 ve verzi Oreo. Nyní Google nařizuje, aby všechna zařízení spouštěná se systémem Android Pie podporovala Verified Boot a tím i ochranu proti vrácení.

Ochrana proti vrácení v Android Oreo

Podstatou této funkce je, že zabrání spuštění telefonu, pokud zjistí, že zařízení bylo downgradováno na dřívější, nyní neschválenou verzi softwaru, která byla považována za nezabezpečenou z důvodu zabezpečení zranitelnost. Trochu techničtější vysvětlení je, že datová struktura VBMeta, která obsahuje hash pro spouštěcí oddíl a metadata hashtree pro systémové oddíly a oddíly dodavatele, používá index vrácení k odmítnutí obrázků, které mají starší vrácení zpět index.

Tato funkce je přítomna na zařízeních jako Google Pixel 2, Razer Phone a OnePlus 6, ale není přítomna na mnoha dalších zařízeních, jako je Samsung Galaxy S9 (ačkoli Samsung nabízí vlastní formu ochrana proti vrácení v Knox.) Nyní společnost Google tuto funkci zavádí jako povinnou pro všechna zařízení se systémem Android Pie.

Ověřené spouštění v Android Pie

Podle aktualizovaného znění v části „Integrita zařízení“ v dokumentu Definice kompatibility musí zařízení se systémem Android 9 podporovat Verified Boot.

9.10. Integrita zařízení

Následující požadavky zajišťují transparentnost stavu integrity zařízení. Implementace zařízení:

• [C-0-1] MUSÍ správně hlásit prostřednictvím metody System API PersistentDataBlockManager.getFlashLockState(), zda jejich stav bootloaderu povoluje flashování obrazu systému. Stav FLASH_LOCK_UNKNOWN je vyhrazen pro implementace zařízení upgradující ze starší verze Androidu, kde tato nová metoda systémového rozhraní API neexistovala.
• [C-0-2] MUSÍ podporovat Verified Boot pro integritu zařízení.

Pokud jsou implementace zařízení již spuštěny bez podpory Verified Boot na dřívější verzi Androidu a nemohou přidat podporu pro tuto funkci aktualizací systémového softwaru, MOHOU být osvobozeni od požadavek.

...

• [C-1-10] MUSÍ implementovat ochranu proti vrácení zpět pro oddíly používané systémem Android (např. spouštěcí, systémové oddíly) a pro ukládání metadat používaných k určení minimálního přípustného operačního systému používat úložiště s viditelným poškozením verze.
• MĚLI BY Implementovat ochranu proti vrácení pro jakoukoli komponentu s trvalým firmwarem (např. modem, kamera) a MĚLI BY POUŽÍVAT úložiště s evidencí neoprávněné manipulace pro ukládání metadat používaných pro stanovení minimálního přípustného množství verze.

Jak můžete vidět v posledních dvou sadě odrážek, je třeba si uvědomit jedno upozornění. Ochrana proti vrácení změn je vyžadována pro oddíly používané systémem Android (boot, systém, dodavatel atd.), ale nikoli pro oddíly s trvalým firmwarem (modem, kamera atd.). V dřívější sadě oddílů se objevuje a opravuje většina bezpečnostních zranitelností, takže je hezké vidět, že ochrana těchto oddílů je povinná. Vyskytly se však exploity, které cílí i na oddíly s trvalým firmwarem, takže si nejsme jisti, proč u nich Google nenařizuje ochranu proti vrácení.

Senior člen XDA npjohnson, člen týmu LineageOS, spekuluje o tom, že by vyžadovala ochranu před vrácením změn na oddílech s perzistentním firmwarem vyžadují propojení sekundárního zavaděče (SBL) a eXtensible Bootloaderu (XBL), protože tyto oddíly jsou připojeny dříve při zavádění proces. Pro menší výrobce OEM by bylo nákladné implementovat přizpůsobené XBL tak, aby odpovídaly přizpůsobeným modemům a dalším trvalým oddílům, takže možná to Google nestanoví jako požadavek, aby výrobcům zařízení usnadnil splnění nejnovějších požadavků v CDD.

Jak zkontrolovat, zda váš telefon podporuje AVB 2.0

Existují dva příkazy prostředí ADB, které můžete použít ke kontrole, zda váš telefon podporuje AVB 2.0.

adb shell
dumpsys package | grep "verified_boot"

NEBO

adb shell
getprop | grep "avb"

Pokud je výstupem prvního příkazu „android.software.verified_boot“, pak je podporováno AVB 2.0. Pokud výstup druhého příkazu zobrazuje „[ro.boot.avb_version]“ a „[ro.boot.vbmeta.avb_version]“ a uvádí číslo verze pro každý z nich, pak je podporován.

Ověřený vývoj spouštění a vlastní vývoj

Android Verified Boot ve skutečnosti neovlivňuje většinu vlastních uživatelů ROM, i když přidává další vrstvu zabezpečení, kterou musíte v některých případech obejít. Například, blikání obecného obrazu systému vyžaduje deaktivaci AVB. Úprava určitých oddílů, jako je dodavatel na OnePlus 6, vyžaduje také deaktivaci AVB, jak jsem se nedávno dozvěděl. Podle npjohnson, správně implementované AVB 2.0 umožňuje, aby vlastní zaváděcí obrazy fungovaly s uzamčeným zavaděčem. Uvidíme, jak zahrnutí AVB 2.0 do zařízení dodávaných s Android Pie ovlivní krajinu, ale doufáme, že to nepovede k situacím, jako je nedávné cihlové zděšení v komunitě Xiaomi Redmi Note 5 Pro. Povinné AVB 2.0 je pro Google jen dalším způsobem zlepšit zabezpečení platformy Android, ale největší změnou je podle našeho názoru přepracování dohod OEM, aby nařídily pravidelné opravy zabezpečení.