Como funcionam as atualizações mensais do patch de segurança do Android

O Google publica boletins de segurança mensais desde agosto de 2015. Esses boletins de segurança contêm uma lista de vulnerabilidades de segurança divulgadas que foram corrigidas e que afetam a estrutura do Android, o kernel do Linux e outros componentes de fornecedores de código fechado. Cada vulnerabilidade nos boletins foi descoberta pelo Google ou divulgado à empresa. Cada vulnerabilidade listada tem um número de Vulnerabilidades e Exposições Comuns (CVE), juntamente com referências, o tipo de vulnerabilidade, uma avaliação de gravidade e a versão AOSP afetada (se aplicável). Mas, apesar do processo aparentemente simplista por trás do funcionamento dos patches de segurança do Android, há na verdade uma certa complicadas idas e vindas nos bastidores que permitem que seu telefone receba mensalmente ou (espero) quase mensalmente manchas.

O que realmente constitui um patch de segurança?

Você deve ter notado que todo mês, na verdade, há dois níveis de patch de segurança. O formato desses patches é AAAA-MM-01 ou AAAA-MM-05. Embora AAAA e MM representem obviamente o ano e o mês, respectivamente, "01" e "05", de forma confusa, não significam realmente o dia do mês em que o nível do patch de segurança foi lançado. Em vez disso, 01 e 05 são, na verdade, dois níveis diferentes de patch de segurança lançados no mesmo dia todos os meses - o nível de patch com 01 no final contém correções para a estrutura do Android, mas não patches de fornecedores ou patches upstream do kernel Linux. Os patches do fornecedor, conforme definimos acima, referem-se a correções em componentes de código fechado, como drivers para Wi-Fi e Bluetooth. O nível de patch de segurança indicado por -05 contém esses patches do fornecedor, bem como patches no kernel do Linux. Dê uma olhada na tabela abaixo que pode ajudar na compreensão.

É claro que alguns OEMs também podem optar por incluir seus próprios patches e atualizações em atualizações de segurança. A maioria dos OEMs tem sua própria opinião sobre o Android, então faz sentido que você tenha, por exemplo, uma vulnerabilidade em um telefone Samsung que não existe em um Huawei. Muitos desses OEMs também publicam seus próprios boletins de segurança.

• Google Pixel
• Huawei
• LG
• Motorola
• HMD Global
• Samsung

A linha do tempo de um patch de segurança do Google para o seu telefone

Os patches de segurança têm um cronograma que abrange aproximadamente 30 dias, embora nem todo OEM possa aproveitar todo esse cronograma. Vamos dar uma olhada no Patch de segurança de maio de 2019 por exemplo, e podemos detalhar todo o cronograma por trás da criação deste patch. Empresas como Essencial conseguem obter suas atualizações de segurança no mesmo dia como o Google Pixel, então como eles fazem isso? A resposta curta e simples é que eles são um Parceiro Android. O boletim de segurança de maio de 2019 foi publicado no dia 6 de maio, com o Google Pixels e o Essential Phone recebendo atualizações quase imediatas.

O que significa ser um parceiro Android

Nem qualquer empresa pode ser parceira do Android, embora basicamente todos os principais OEMs do Android o sejam. Parceiros Android são empresas que recebem licença para usar a marca Android em material de marketing. Eles também podem enviar Google Mobile Services (GMS - refere-se a praticamente todos os serviços do Google), desde que atendam aos requisitos descritos no Documento de definição de compatibilidade (CDD) e passar no Compatibility Test Suite (CTS), Vendor Test Suite (VTS), Google Test Suite (GTS) e alguns outros testes. Existem diferenças distintas no processo de patch de segurança para empresas que não são um parceiro Android.

• Os patches da estrutura Android estão disponíveis para eles após serem incorporados ao AOSP 1 a 2 dias antes do lançamento do boletim de segurança.
• Os patches upstream do kernel Linux podem ser escolhidos a dedo assim que estiverem disponíveis.
• Correções de fornecedores de SoC para componentes de código fechado estão disponíveis dependendo dos acordos com o fornecedor de SoC. Observe que se o fornecedor concedeu ao OEM acesso ao código-fonte do(s) componente(s) de código fechado, o(s) próprio(s) OEM(s) poderá(m) corrigir o(s) problema(s). Se o OEM não tiver acesso ao código-fonte, ele deverá aguardar que o fornecedor emita uma correção.

Se você é um parceiro Android, tudo fica muito mais fácil imediatamente. Os parceiros Android são notificados sobre todos os problemas da estrutura do Android e do kernel do Linux pelo menos 30 dias antes de o boletim ser tornado público. O Google fornece patches para todos os problemas para os OEMs mesclarem e testarem, embora os patches dos componentes do fornecedor dependam do fornecedor. Patches para problemas da estrutura do Android divulgados no boletim de segurança de maio de 2019, por exemplo, foram fornecidos aos parceiros Android pelo menos já em 20 de março de 2019*. Aquilo é um muito de prorrogação.

*Observação: o Google pode, e frequentemente o faz, atualizar os patches do boletim de segurança mais recente até o lançamento público. Essas atualizações podem acontecer se novas vulnerabilidades e bugs forem encontrados, se o Google decidir remover determinados patches do boletim mensal devido à quebra de componentes críticos, se o Google atualizar um patch para resolver um bug criado pela versão anterior do patch e outros razões.

Por que preciso esperar tanto para receber um patch de segurança no meu telefone?

Embora seja verdade que os parceiros Android (leia-se: todos os principais OEMs) receberam patches de segurança bem antes de seus lançamento, muitos estão dolorosamente cientes de que possivelmente não receberão uma atualização de segurança por meses após seu lançamento. liberar. Geralmente, isso se deve a um dos quatro motivos.

• Os OEMs podem precisar fazer grandes alterações técnicas para acomodar um patch de segurança, pois ele pode entrar em conflito com o código existente.
• O fornecedor é lento no fornecimento de código-fonte atualizado para componentes de código fechado.
• A certificação da operadora pode levar algum tempo.
• As empresas podem não estar dispostas a lançar uma atualização de segurança sem lançar um recurso ao mesmo tempo.

Embora todos esses sejam motivos válidos para uma empresa não lançar um patch de segurança, o usuário final nem sempre se preocupa com nenhum deles. É certo que o usuário final nem sempre se preocupa com os patches de segurança, embora devesse. Iniciativas como o Projeto Treble, Linux LTS estendido, e Linha principal do projeto estão ajudando a eliminar as dificuldades técnicas de fusão desses patches de segurança, mas isso não é suficiente para fazer com que os OEMs se esforcem consistentemente para lançar atualizações. Com uma imagem genérica do kernel, ou GKI, os fornecedores de SoC e OEMs terão mais facilidade para mesclar patches upstream do kernel Linux, embora provavelmente não veremos os primeiros dispositivos com GKI até o próximo ano.

Mas uma informação interessante que a maioria não sabe é que os principais OEMs deve fornecer “pelo menos quatro atualizações de segurança” dentro de um ano após o lançamento do dispositivo e 2 anos de atualizações no geral. O Google não confirmou esses termos específicos, mas a empresa confirmou que “trabalhou na integração de patches de segurança em [seus] contratos OEM”. Quanto aos dispositivos Android Enterprise Recomendado (AER), os dispositivos são obrigados a obter atualizações de segurança dentro de 90 dias após o lançamento, durante 3 anos. Dispositivos AER robustos são necessários para obter 5 anos de atualizações de segurança. Os dispositivos Android One devem receber atualizações de segurança todos os meses durante 3 anos.

O que há em um patch de segurança?

Um patch de segurança é apenas mais uma atualização, embora geralmente muito menor, com alterações em estruturas individuais e módulos do sistema, em vez de melhorias ou alterações em todo o sistema. Todo mês, o Google fornece aos OEMs de dispositivos um arquivo zip que contém patches para todas as principais versões do Android ainda suportadas, junto com um conjunto de testes de segurança. Este conjunto de testes ajuda os OEMs a detectar lacunas nos patches de segurança, para garantir que eles não percam nada e que os patches foram mesclados adequadamente. Com o passar do mês, o Google pode fazer pequenas revisões, como decidir que um patch específico é opcional, especificamente se houver problemas para implementá-lo.

E quanto às ROMs personalizadas?

Se o seu smartphone não receber muitas atualizações de segurança, isso não significa necessariamente que seja melhor mudar para uma ROM personalizada. Embora seja verdade que você receberá atualizações de segurança que não receberia de outra forma, isso é apenas metade da história. Desbloquear seu bootloader deixa você suscetível a ataques físicos em seu dispositivo, mesmo que no lado do software a segurança seja reforçada. Isso não quer dizer que você não deva usar ROMs personalizados, apenas que existem outras preocupações quando se trata de usá-los que não se aplicam se o seu bootloader for mantido bloqueado. Se você está mais preocupado com o lado do software, então é melhor usar uma ROM personalizada que receba patches de segurança frequentes.

Mas lembra que falamos sobre a diferença entre os patches AAAA-MM-01 e AAAA-MM-05? O nível de patch -05 contém patches do kernel Linux, bem como patches de fornecedores – patches aplicados a software de código fechado. Isso significa que os desenvolvedores de ROM personalizados estão à mercê de qualquer OEM para o qual estão desenvolvendo e se o OEM lança blobs atualizados ou não. Isso é adequado para dispositivos que ainda são atualizados pelo fabricante, mas para dispositivos que não o são, os patches aplicados só podem ser aplicados à estrutura do Android e ao kernel do Linux. É por isso que o LineageOS Interface de confiança mostra dois níveis de patch de segurança - um sendo plataforma e outro sendo fornecedor. Mesmo que ROMs personalizadas para dispositivos não suportados não possam integrar totalmente todos os patches mais recentes, elas serão mais seguras do que as ROMs mais antigas e desatualizadas.