Защитата за връщане на Android Oreo се изисква на телефони, стартиращи с Android Pie

Android Pie (Android 9) току-що беше на живо днес за Google Pixel, Google Pixel 2 и дори и Основен телефон. Научаваме колкото можем повече за изданието от интервюта (Google Pixel 3 ще има само навигация с жестове!), на Отпадане на AOSP код, и накрая документа за определяне на съвместимостта (CDD). Публикувахме за a нова функция за "тежки" приложения по-рано днес, но сега открихме, че Google е променил формулировката си относно функция, въведена в Android Oreo: защита от връщане назад. Функцията е възможна от Android Verified Boot 2.0 (известен също просто като Verified Boot), обаче, от OEM производителите не се изискваше да внедрят AVB 2.0 в изданието Oreo. Сега Google налага всички устройства, стартирани с Android Pie, да поддържат Verified Boot и като разширение защита срещу връщане назад.

Защита от връщане назад в Android Oreo

Същността на функцията е, че тя ще попречи на телефона ви да се зарежда, ако установи, че устройството е с по-ниска версия към по-ранна, сега неодобрена версия на софтуер, който е смятан за несигурен поради сигурност уязвимост. Малко по-техническо обяснение е, че структурата на данните VBMeta, която съдържа хеша за началния дял и hashtree метаданни за системни дялове и дялове на доставчици, използва индекс за връщане назад, за да отхвърли изображения, които имат по-старо връщане индекс.

Тази функция присъства на устройства като Google Pixel 2, Razer Phone и OnePlus 6, но не присъства на много други устройства като Samsung Galaxy S9 (въпреки че Samsung предлага своя собствена форма на защита от връщане назад в Knox.) Сега Google прави функцията задължителна за всяко устройство, стартирано с Android Pie.

Проверено зареждане в Android Pie

Според актуализираната формулировка в раздела „Интегритет на устройството“ в документа за дефиниция на съвместимост, устройствата, които се стартират с Android 9, трябва да поддържат Verified Boot.

9.10. Цялост на устройството

Следните изисквания гарантират прозрачност на състоянието на целостта на устройството. Реализации на устройства:

• [C-0-1] ТРЯБВА да докладва правилно чрез метода на System API PersistentDataBlockManager.getFlashLockState() дали тяхното състояние на буутлоудъра позволява мигане на системния образ. Състоянието FLASH_LOCK_UNKNOWN е запазено за внедрявания на устройства, надграждащи се от по-ранна версия на Android, където този нов системен API метод не съществува.
• [C-0-2] ТРЯБВА да поддържа Verified Boot за целостта на устройството.

Ако внедряванията на устройства вече са стартирани без поддръжка на Verified Boot на по-ранна версия на Android и не могат да добавят поддръжка за тази функция с актуализация на системния софтуер, те МОЖЕ да бъдат освободени от изискване.

...

• [C-1-10] ТРЯБВА да внедри защита за връщане назад за дялове, използвани от Android (напр. зареждане, системни дялове) и използвайте защитено от подправяне хранилище за съхраняване на метаданните, използвани за определяне на минималната допустима ОС версия.
• ТРЯБВА ДА внедри защита срещу връщане за всеки компонент с постоянен фърмуер (напр. модем, камера) и ТРЯБВА да използва защитено от подправяне хранилище за съхраняване на метаданните, използвани за определяне на минимално допустимото версия.

Както можете да видите в последните два набора от точки, има едно предупреждение, което трябва да се отбележи. Защитата от връщане се изисква за дялове, използвани от Android (зареждане, система, доставчик и т.н.), но не и за дялове с постоянен фърмуер (модем, камера и т.н.). Първият набор от дялове е мястото, където повечето от уязвимостите в сигурността са открити и коригирани, така че е хубаво да се види, че защитата на тези дялове е задължителна. Има обаче експлойти, които са насочени и към дялове с постоянен фърмуер, така че не сме сигурни защо Google не изисква защита срещу връщане към тях.

Старши член на XDA npjohnson, член на екипа на LineageOS, спекулира, че изискването за защита от връщане назад на дялове с постоянен фърмуер би изискват свързване на Secondary Bootloader (SBL) и eXtensible Bootloader (XBL), тъй като тези дялове са монтирани по-рано в зареждането процес. Би било скъпо за по-малките OEM производители да внедрят персонализирани XBL, за да съответстват на персонализираните модеми и други постоянни дялове, така че може би Google не поставя това като изискване, за да улесни производителите на устройства да отговарят на най-новите изисквания в CDD.

Как да проверите дали вашият телефон поддържа AVB 2.0

Има две команди на ADB shell, които можете да използвате, за да проверите дали телефонът ви поддържа AVB 2.0.

adb shell
dumpsys package | grep "verified_boot"

ИЛИ

adb shell
getprop | grep "avb"

Ако резултатът от първата команда е "android.software.verified_boot", тогава AVB 2.0 се поддържа. Ако изходът на втората команда показва „[ro.boot.avb_version]“ и „[ro.boot.vbmeta.avb_version]“ и изброява номер на версия за всяка, тогава тя се поддържа.

Проверено зареждане и персонализирана разработка

Android Verified Boot всъщност не засяга повечето потребители на потребителски ROM, въпреки че добавя допълнителен слой сигурност, който трябва да заобиколите в някои случаи. Например, мигане на Generic System Image изисква деактивиране на AVB. Модифицирането на определени дялове като доставчик на OnePlus 6 изисква също деактивиране на AVB, както наскоро научих. Според npjohnson, правилно внедреният AVB 2.0 прави възможно персонализираните изображения за зареждане да работят със заключен зареждащ механизъм. Ще видим как включването на AVB 2.0 на устройства, доставяни с Android Pie, се отразява на пейзажа, но се надяваме, че няма да доведе до ситуации като скорошен страх от тухли в общността на Xiaomi Redmi Note 5 Pro. Задължителният AVB 2.0 е просто друг начин за Google подобряване на сигурността на платформата Android, но най-голямата промяна според нас е преработване на OEM споразумения за налагане на редовни корекции за сигурност.