Se requiere protección de reversión de Android Oreo en teléfonos que se inician con Android Pie

Pastel de Android (Android 9) acaba de salir en vivo hoy para Google Pixel, Google Pixel 2 y incluso el Teléfono esencial. Estamos aprendiendo todo lo que podemos sobre el lanzamiento a través de entrevistas (el Google Pixel 3 solo tendrá navegación por gestos!), el Caída de código AOSPy por último el Documento de Definición de Compatibilidad (CDD). Publicamos sobre un nueva característica para aplicaciones "pesadas" Hoy, pero ahora descubrimos que Google ha cambiado la redacción de una característica introducida en Android Oreo: protección de reversión. La característica es posible gracias a Arranque verificado de Android 2.0 (también conocido simplemente como arranque verificado), sin embargo, los OEM no estaban obligados a implementar AVB 2.0 en la versión de Oreo. Ahora, Google exige que todos los dispositivos que se inicien con Android Pie admitan el arranque verificado y, por extensión, la protección contra reversión.

Protección de reversión en Android Oreo

La esencia de la función es que evitará que su teléfono se inicie si detecta que el dispositivo fue degradado. a una versión anterior, ahora no aprobada, de software que se ha considerado inseguro debido a un problema de seguridad vulnerabilidad. Una explicación un poco más técnica es que la estructura de datos VBMeta, que contiene el hash de la partición de arranque y Metadatos de hashtree para particiones del sistema y del proveedor, utiliza un índice de reversión para rechazar imágenes que tienen una reversión anterior. índice.

Esta función está presente en dispositivos como Google Pixel 2, Razer Phone y OnePlus 6, pero no está presente en muchos otros dispositivos como el Samsung Galaxy S9 (aunque Samsung ofrece su propia forma de protección de reversión en Knox.) Ahora, Google está haciendo que la función sea obligatoria para cualquier dispositivo que se inicie con Android Pie.

Arranque verificado en Android Pie

Según la redacción actualizada en la sección "Integridad del dispositivo" en el Documento de definición de compatibilidad, los dispositivos que se inician con Android 9 deben admitir el arranque verificado.

9.10. Integridad del dispositivo

Los siguientes requisitos garantizan que haya transparencia en el estado de integridad del dispositivo. Implementaciones de dispositivos:

• [C-0-1] DEBE informar correctamente a través del método API del sistema PersistentDataBlockManager.getFlashLockState() si el estado de su cargador de arranque permite la actualización de la imagen del sistema. El estado FLASH_LOCK_UNKNOWN está reservado para implementaciones de dispositivos que se actualizan desde una versión anterior de Android donde este nuevo método API del sistema no existía.
• [C-0-2] DEBE admitir el arranque verificado para la integridad del dispositivo.

Si las implementaciones de dispositivos ya se iniciaron sin admitir el arranque verificado en una versión anterior de Android y no pueden agregar soporte para esta función con una actualización del software del sistema, PUEDEN estar exentos del requisito.

...

• [C-1-10] DEBE implementar protección de reversión para las particiones utilizadas por Android (por ejemplo, arranque, particiones del sistema) y utilizar almacenamiento a prueba de manipulaciones para almacenar los metadatos utilizados para determinar el sistema operativo mínimo permitido versión.
• DEBE implementar protección de reversión para cualquier componente con firmware persistente (por ejemplo, módem, cámara) y DEBE utilizar almacenamiento a prueba de manipulaciones para almacenar los metadatos utilizados para determinar el mínimo permitido. versión.

Como puede ver en los dos últimos puntos, hay una advertencia a tener en cuenta. Se requiere protección de reversión para las particiones utilizadas por Android (arranque, sistema, proveedor, etc.), pero no para las particiones con firmware persistente (módem, cámara, etc.). El primer conjunto de particiones es donde se descubren y reparan la mayoría de las vulnerabilidades de seguridad, por lo que es bueno ver que proteger estas particiones es obligatorio. Sin embargo, también ha habido exploits que apuntan a particiones con firmware persistente, por lo que no estamos seguros de por qué Google no exige protección de reversión en ellas.

Miembro senior de XDA npjohnson, miembro del equipo de LineageOS, especula que requerir protección de reversión en particiones con firmware persistente Requieren conexiones del cargador de arranque secundario (SBL) y del cargador de arranque extensible (XBL), ya que estas particiones se montan antes en el arranque. proceso. Sería costoso para los OEM más pequeños implementar XBL personalizados para que coincidan con los módems personalizados y otras particiones persistentes. Entonces, tal vez Google no esté haciendo de esto un requisito para facilitar que los fabricantes de dispositivos cumplan con los últimos requisitos del CDD.

Cómo comprobar si su teléfono es compatible con AVB 2.0

Hay dos comandos de shell ADB que puede usar para verificar si su teléfono es compatible con AVB 2.0.

adb shell
dumpsys package | grep "verified_boot"

O

adb shell
getprop | grep "avb"

Si el resultado del primer comando es "android.software.verified_boot", entonces se admite AVB 2.0. Si el resultado del segundo comando muestra "[ro.boot.avb_version]" y "[ro.boot.vbmeta.avb_version]" y enumera un número de versión para cada uno, entonces es compatible.

Arranque verificado y desarrollo personalizado

El arranque verificado de Android realmente no afecta a la mayoría de los usuarios de ROM personalizados, aunque agrega una capa adicional de seguridad que debe solucionarse en algunos casos. Por ejemplo, mostrar una imagen genérica del sistema requiere desactivar AVB. Modificar ciertas particiones como el proveedor en OnePlus 6 también requiere deshabilitar AVB. como aprendí recientemente. De acuerdo a npjohnson, AVB 2.0 implementado correctamente hace posible que las imágenes de arranque personalizadas funcionen con un gestor de arranque bloqueado. Veremos cómo afecta al panorama la inclusión de AVB 2.0 en los dispositivos que vienen con Android Pie, pero esperamos que no resulte en situaciones como la susto reciente de ladrillos en la comunidad Xiaomi Redmi Note 5 Pro. El AVB 2.0 obligatorio es sólo otra forma que tiene Google de mejorar la seguridad de la plataforma Android, pero el mayor cambio, en nuestra opinión, es la Reelaboración de los acuerdos OEM para exigir parches de seguridad periódicos..