IA

Google muda as regras do jogo dos patches de segurança Android

Novas bibliotecas AndroidX deixam de tratar a data do patch como verdade absoluta. Apps passam a ver, ao detalhe, que falhas de segurança estão mesmo corrigidas no teu telemóvel.

Google muda as regras do jogo dos patches de segurança Android
Ilustração digital | Pixel Magazine

Durante anos, a data do patch de segurança no Android foi tratada como um selo quase religioso: se estava recente, sossego, se estava velha, alarme. A partir de hoje, com as novas bibliotecas AndroidX Security State e Security State Provider, a Google assume finalmente em público aquilo que os engenheiros já sabiam: essa data é um resumo grosso e, muitas vezes, enganador.

O Android é modular há muito tempo. Parte das correções chega via o fabricante, em atualizações de sistema, outra parte aterra discretamente através dos serviços Google Play, sem subir o número de versão nem mexer na data do patch. Resultado: dois telemóveis podem mostrar a mesma data, mas ter conjuntos de correções bem diferentes. Agora, com as bibliotecas AndroidX Security State, as apps passam a conseguir perguntar ao sistema: que falhas específicas já estão corrigidas neste dispositivo, quais faltam e se há updates pendentes à espera de reboot.

Isto é ouro para apps de risco elevado, como as de banca ou carteira digital, que até aqui trabalhavam com um semáforo simplista. Em vez de bloquearem só porque a data do patch está atrasada, podem verificar se a vulnerabilidade concreta que lhes interessa foi corrigida. Falta um patch crítico de NFC que afeta pagamentos por aproximação, mas já está descarregado e pronto a instalar? A app pode dizer-te para reiniciares o telemóvel antes de aprovar uma transferência, em vez de te atirar um erro opaco. Para quem já anda a seguir guias como o nosso sobre como caçar e remover spyware do teu telemóvel Android, isto é mais uma peça no puzzle da proteção séria.

Há outro detalhe importante: os fabricantes podem incluir correções específicas sem tocar na data global do patch. Com o Android 17, os OEM passam a poder dizer explicitamente ao sistema que CVE X ou Y foi tratado, e as novas bibliotecas expõem essa informação às apps. Traduzindo, o teu telemóvel pode continuar a mostrar um patch de julho, mas já ter, por baixo, o remendo para uma falha Bluetooth crítica de agosto. Para utilizadores regulares isto passa-se todo nos bastidores, mas para equipas de segurança e para quem gere frotas de dispositivos, é a diferença entre trabalhar às escuras ou com um mapa decente.

Há, claro, um lado menos simpático: mais poder nas mãos das apps é também mais margem para abuso. Uma coisa é uma app de banco validar meia dúzia de CVE críticas antes de te deixar mexer em dinheiro. Outra é cada app mediana decidir que não corre se o teu patch não estiver com menos de 30 dias, ou começar a exigir um nível de segurança que não corresponde ao risco real. A tentação de transformar estas APIs em mais um filtro burocrático e em mais dados de telemetria é grande, e a Google não tem exatamente o melhor histórico a pôr travões em developers agressivos.

Mesmo assim, tecnicamente, a jogada faz sentido. A segurança moderna vive de detalhe, não de datas de calendário. O Windows aprendeu isto à força, depois de anos de Tuesdays caóticas e patches fora de ciclo, a ponto de a própria Microsoft ter de lançar patches de emergência para corrigir patches anteriores. O Android está a fazer o mesmo caminho, só que com um mosaico bem mais fragmentado de fabricantes e versões. Se as apps souberem usar estas novas bibliotecas com cabeça, pode ser o início de uma discussão mais adulta sobre segurança em Android: menos fetiche com a data do patch, mais foco em que falhas concretas é que estão mesmo tapadas.

Fonte: Android Authority

Comentários · 0