На телефонах, запускаемых с Android Pie, требуется защита от отката Android Oreo

Android пирог (Android 9) только сегодня вышел в эфир для Google Pixel, Google Pixel 2 и даже Необходимый телефон. Мы узнаем как можно больше о выпуске из интервью (Google Pixel 3 будет только навигация жестами!), Удаление кода AOSPи, наконец, Документ определения совместимости (CDD). Мы публиковали информацию о новая функция для «тяжеловесных» приложений ранее сегодня, но теперь мы обнаружили, что Google изменил формулировку функции, представленной в Android Oreo: защита от отката. Эта функция стала возможной благодаря Android проверенная загрузка 2.0 (также известный как «Проверенная загрузка»), однако OEM-производителям не требовалось внедрять AVB 2.0 в выпуске Oreo. Теперь Google требует, чтобы все устройства, запускаемые с Android Pie, поддерживали проверенную загрузку и, как следствие, защиту от отката.

Защита от отката в Android Oreo

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

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

Проверенная загрузка в Android Pie

Согласно обновленной формулировке в разделе «Целостность устройства» документа с определением совместимости, устройства, запускаемые с Android 9, должны поддерживать проверенную загрузку.

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

Следующие требования обеспечивают прозрачность состояния целостности устройства. Реализации устройства:

• [C-0-1] ДОЛЖЕН правильно сообщать через метод системного API PersistentDataBlockManager.getFlashLockState(), разрешает ли состояние их загрузчика мигание образа системы. Состояние FLASH_LOCK_UNKNOWN зарезервировано для обновления реализаций устройства с более ранней версии Android, где этот новый метод системного API не существовал.
• [C-0-2] ДОЛЖЕН поддерживать проверенную загрузку для обеспечения целостности устройства.

Если реализации устройств уже запущены без поддержки Verified Boot в более ранней версии Android и не могут добавить поддержку этой функции в обновлении системного программного обеспечения, они МОГУТ быть освобождены от требование.

...

• [C-1-10] НЕОБХОДИМО реализовать защиту от отката для разделов, используемых Android (например, загрузочные, системные разделы). и использовать защищенное от несанкционированного доступа хранилище для хранения метаданных, используемых для определения минимально допустимой ОС. версия.
• СЛЕДУЕТ реализовать защиту от отката для любого компонента с постоянной прошивкой (например, модема, камеры) и СЛЕДУЕТ использовать хранилище с защитой от несанкционированного доступа для хранения метаданных, используемых для определения минимально допустимого версия.

Как вы можете видеть из двух последних пунктов, следует отметить одну оговорку. Защита от отката необходима для разделов, используемых Android (загрузочный, системный, вендорный и т. д.), но не для разделов с постоянной прошивкой (модем, камера и т. д.). В первом наборе разделов обнаруживается и исправляется большинство уязвимостей безопасности, поэтому приятно видеть, что защита этих разделов обязательна. Однако были эксплойты, нацеленные и на разделы с постоянной прошивкой, поэтому мы не уверены, почему Google не требует для них защиты от отката.

Старший член XDA Нпджонсон, член команды LineageOS, предполагает, что требование защиты от отката на разделах с постоянной прошивкой может требуют подключения вторичного загрузчика (SBL) и расширяемого загрузчика (XBL), поскольку эти разделы монтируются ранее при загрузке. процесс. Для мелких OEM-производителей было бы затратно внедрять индивидуальные XBL для соответствия настроенным модемам и другим постоянным разделам. так что, возможно, Google не делает это требованием, чтобы производителям устройств было проще соответствовать последним требованиям CDD.

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

Есть две команды оболочки ADB, которые вы можете использовать, чтобы проверить, поддерживает ли ваш телефон 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 на самом деле не влияет на большинство пользователей пользовательских ПЗУ, хотя в некоторых случаях он добавляет дополнительный уровень безопасности, с которым вам придется обходиться. Например, прошивка общего образа системы требует отключения AVB. Изменение определенных разделов, таких как поставщик в OnePlus 6, также требует отключения AVB. как я недавно узнал. В соответствии с НпджонсонПравильно реализованный AVB 2.0 позволяет пользовательским загрузочным образам работать с заблокированным загрузчиком. Посмотрим, как включение AVB 2.0 на устройства, поставляемые с Android Pie, повлияет на ситуацию, но мы надеемся, что это не приведет к таким ситуациям, как недавний страх перед кирпичом в сообществе Xiaomi Redmi Note 5 Pro. Обязательный AVB 2.0 — это еще один способ для Google улучшить безопасность платформы Android, но самым большим изменением, на наш взгляд, является переработка OEM-соглашений для обязательного регулярного внесения исправлений безопасности.