Proteção contra reversão do Android Oreo necessária em telefones lançados com Android Pie

Torta Android (Android 9) acabei de entrar ao vivo hoje para o Google Pixel, Google Pixel 2 e mesmo o Telefone essencial. Estamos aprendendo o máximo que podemos sobre o lançamento por meio de entrevistas (o Google Pixel 3 terá apenas navegação por gestos!), o Queda de código AOSPe, por último, o Documento de Definição de Compatibilidade (CDD). Postamos sobre um novo recurso para aplicativos "pesados" hoje cedo, mas agora descobrimos que o Google mudou o texto de um recurso introduzido no Android Oreo: proteção contra reversão. O recurso é possível graças Inicialização verificada do Android 2.0 (também conhecido simplesmente como inicialização verificada), no entanto, os OEMs não eram obrigados a implementar o AVB 2.0 na versão Oreo. Agora, o Google exige que todos os dispositivos lançados com Android Pie suportem inicialização verificada e, por extensão, proteção contra reversão.

Proteção contra reversão no Android Oreo

A essência do recurso é que ele impedirá a inicialização do telefone se detectar que o dispositivo foi rebaixado para uma versão anterior, agora não aprovada, de software que foi considerada insegura devido a um problema de segurança vulnerabilidade. Uma explicação um pouco mais técnica é que a estrutura de dados VBMeta, que contém o hash da partição de inicialização e metadados hashtree para partições de sistema e de fornecedor, usa um índice de reversão para rejeitar imagens que possuem uma reversão mais antiga índice.

Este recurso está presente em dispositivos como Google Pixel 2, Razer Phone e OnePlus 6, mas não está presente em muitos outros dispositivos como o Samsung Galaxy S9 (embora a Samsung ofereça sua própria forma de proteção contra reversão em Knox.) Agora, o Google está tornando o recurso obrigatório para qualquer dispositivo lançado com Android Pie.

Inicialização verificada no Android Pie

De acordo com o texto atualizado na seção "Integridade do dispositivo" no Documento de definição de compatibilidade, os dispositivos iniciados com Android 9 devem oferecer suporte à inicialização verificada.

9.10. Integridade do dispositivo

Os requisitos a seguir garantem transparência no status da integridade do dispositivo. Implementações de dispositivos:

• [C-0-1] DEVE relatar corretamente por meio do método PersistentDataBlockManager.getFlashLockState() da API do sistema se o estado do carregador de inicialização permite o flash da imagem do sistema. O estado FLASH_LOCK_UNKNOWN é reservado para implementações de dispositivos atualizadas de uma versão anterior do Android onde esse novo método de API do sistema não existia.
• [C-0-2] DEVE oferecer suporte à inicialização verificada para integridade do dispositivo.

Se as implementações de dispositivos já tiverem sido lançadas sem compatibilidade com inicialização verificada em uma versão anterior do Android e não puderem adicionar suporte para esse recurso com uma atualização de software do sistema, eles PODEM ficar isentos da requerimento.

...

• [C-1-10] DEVE implementar proteção contra reversão para partições usadas pelo Android (por exemplo, inicialização, partições do sistema) e usar armazenamento inviolável para armazenar os metadados usados ​​para determinar o sistema operacional mínimo permitido versão.
• DEVE implementar proteção contra reversão para qualquer componente com firmware persistente (por exemplo, modem, câmera) e DEVE usar armazenamento inviolável para armazenar os metadados usados ​​para determinar o mínimo permitido versão.

Como você pode ver nos dois últimos conjuntos de marcadores, há uma advertência a ser observada. A proteção contra reversão é necessária para partições usadas pelo Android (inicialização, sistema, fornecedor etc.), mas não para partições com firmware persistente (modem, câmera etc.). O antigo conjunto de partições é onde a maioria das vulnerabilidades de segurança são descobertas e corrigidas, por isso é bom ver que a proteção dessas partições é obrigatória. No entanto, houve explorações que também visam partições com firmware persistente, por isso não sabemos por que o Google não exige proteção contra reversão para elas.

Membro Sênior do XDA npjohnson, membro da equipe LineageOS, especula que exigir proteção contra reversão em partições com firmware persistente seria requerem conexões do Secondary Bootloader (SBL) e do eXtensible Bootloader (XBL), uma vez que essas partições são montadas anteriormente na inicialização processo. Seria caro para OEMs menores implementar XBLs personalizados para corresponder aos modems personalizados e outras partições persistentes, então talvez o Google não esteja tornando isso um requisito para facilitar aos fabricantes de dispositivos o atendimento aos requisitos mais recentes do CDD.

Como verificar se o seu telefone suporta AVB 2.0

Existem dois comandos shell ADB que você pode usar para verificar se o seu telefone suporta AVB 2.0.

adb shell
dumpsys package | grep "verified_boot"

OU

adb shell
getprop | grep "avb"

Se a saída do primeiro comando for "android.software.verified_boot", então AVB 2.0 será compatível. Se a saída do segundo comando mostrar "[ro.boot.avb_version]" e "[ro.boot.vbmeta.avb_version]" e listar um número de versão para cada um, então ele será compatível.

Inicialização verificada e desenvolvimento personalizado

A inicialização verificada do Android realmente não afeta a maioria dos usuários de ROM personalizados, embora adicione uma camada extra de segurança que você precisa contornar em alguns casos. Por exemplo, exibindo uma imagem genérica do sistema requer a desativação do AVB. A modificação de certas partições, como fornecedor no OnePlus 6, também requer a desativação do AVB, como aprendi recentemente. De acordo com npjohnson, o AVB 2.0 implementado corretamente possibilita que imagens de inicialização personalizadas funcionem com um gerenciador de inicialização bloqueado. Veremos como a inclusão do AVB 2.0 em dispositivos fornecidos com Android Pie afeta o cenário, mas esperamos que não resulte em situações como a susto recente de tijolos na comunidade Xiaomi Redmi Note 5 Pro. O AVB 2.0 obrigatório é apenas outra maneira do Google melhorar a segurança da plataforma Android, mas a maior mudança, em nossa opinião, é a retrabalho de acordos OEM para exigir patches de segurança regulares.