Porque o atraso nas atualizações do Chromium é importante para a segurança

O Chromium processa dados não fidedignos provenientes de sites, imagens, tipos de letra, conteúdos multimédia, scripts, extensões e protocolos de rede. A sandbox e outras camadas de defesa reduzem o impacto de uma falha, mas não tornam seguro manter indefinidamente uma versão vulnerável. As próprias orientações do Chromium sobre atualizações de segurança indicam que quase todas as atualizações do Chrome contêm correções de segurança e avisam que as vulnerabilidades corrigidas podem tornar-se mais fáceis de explorar em instalações que permaneçam sem correção.

Este aviso tem uma consequência importante para todos os navegadores criados a partir do Chromium: manter a base de código faz parte da manutenção do produto.

O que mede realmente o atraso de uma atualização

É frequente comparar a data de uma versão de um navegador derivado com a data da versão correspondente do Chrome. Esta comparação é útil, mas incompleta. Uma correção não está ativa apenas porque um fornecedor a compilou ou publicou.

Um calendário prático de atualização tem, pelo menos, estes pontos de controlo:

Ponto de controlo	Provas a conservar
Versão a montante	Versão, ramo e hora exatos a montante, bem como o aviso de segurança monitorizado
Incorporação a jusante	Registo de commit ou de equivalência de correção que mostre o que foi incorporado
Candidato pronto	Resultado de compilação reproduzível, testes automatizados e resultados de regressão de segurança
Versão autorizada	Metadados assinados, resumo criptográfico do artefacto, assinatura da plataforma e registo de aprovação
Artefacto disponível	Publicação bem-sucedida em todos os canais de atualização suportados
Instalação no dispositivo	Resultado da instalação verificado por versão e plataforma
Versão corrigida ativa	Reinício do navegador ou substituição do processo confirmados

A janela de exposição de um dispositivo termina na última linha, não na primeira. Se uma atualização for transferida na terça-feira, mas o processo vulnerável do navegador continuar em execução até sexta-feira, esse dispositivo mantém mais três dias de atraso efetivo.

Daqui resultam três medições distintas:

1. Atraso do fornecedor: tempo entre a versão relevante a montante e um artefacto assinado a jusante.
2. Atraso de distribuição: tempo entre a publicação a jusante e a instalação bem-sucedida.
3. Atraso de ativação: tempo entre a disponibilidade da instalação e a entrada em funcionamento do navegador corrigido.

Comunique as três. Uma única média pode ocultar um canal de versões bloqueado, uma falha de assinatura específica de uma plataforma ou uma cauda longa de dispositivos que nunca reiniciam o navegador.

Porque o tempo se torna mais perigoso depois de uma correção ser lançada

As notas de segurança não revelam imediatamente todos os pormenores de implementação. O Chromium afirma que pode manter os detalhes de um erro com acesso restrito até a correção chegar à maioria dos utilizadores, e as suas Perguntas frequentes sobre segurança explicam que muitos relatórios se tornam públicos mais tarde. Esta divulgação coordenada reduz riscos desnecessários, mas não preserva o segredo para sempre.

Depois de uma correção se tornar pública, investigadores e atacantes podem comparar código antigo e novo, analisar testes, observar alterações de comportamento e estudar os metadados da versão. O Chromium chama exploração de vulnerabilidades já corrigidas aos ataques contra instalações antigas depois de uma correção. As suas orientações para navegadores baseados no Chromium recomendam publicar uma versão poucos dias depois de cada versão Chrome Stable, em vez de esperar por um ciclo mensal de funcionalidades.

O arquivo de versões do Chrome demonstra por que razão uma política limitada às versões principais é insuficiente. As atualizações do canal Stable entre marcos contêm correções de segurança, e alguns detalhes permanecem restritos durante a distribuição. Um fornecedor derivado que observe apenas a promoção de ramos principais pode ignorar correções já distribuídas no ramo estável atual.

Um número de versão é uma prova, não uma demonstração completa

Uma versão do Chromium é um sinal inicial forte, pois identifica um ramo e um nível de correção a montante. Ainda assim, não responde por si só a todas as perguntas.

Um navegador derivado pode:

• apresentar um número de versão mais recente enquanto omite uma correção relevante para a segurança;
• utilizar um ramo mais antigo com uma adaptação retroativa documentada;
• incluir a correção no código-fonte, mas não conseguir distribuí-la numa plataforma;
• instalar ficheiros novos enquanto um processo antigo do navegador continua em execução; ou
• reverter para uma versão que reintroduz a vulnerabilidade.

As adaptações retroativas exigem um registo de equivalência que associe a correção a montante à alteração a jusante e às provas dos testes. O Chromium avisa que algumas melhorias de segurança dependem de alterações arquiteturais e não podem ser adaptadas de forma limpa. As notas de versão também não devem ser tratadas como um fluxo completo e seguro de prioridades. As Perguntas frequentes sobre atualizações de segurança do Chrome recomendam aplicar as atualizações na íntegra, em vez de esperar para avaliar apenas as vulnerabilidades descritas publicamente.

Por isso, a pergunta certa para quem avalia não é apenas «Que versão do Chromium é esta?». Pergunte também: «Que versão de segurança a montante está abrangida por esta compilação e como foi verificada essa cobertura na minha plataforma?»

Onde se acumula o atraso a jusante

Um inventário extenso de alterações

Cada alteração profunda ao Chromium cria trabalho de integração futuro. Uma modificação pode entrar em conflito com uma refatoração a montante, depender de interfaces removidas ou invalidar um teste. O custo reaparece em cada atualização de segurança. Um inventário menor e revisto dá à equipa do navegador mais margem para incorporar trabalho urgente a montante.

O número de alterações, por si só, não é uma métrica adequada. Uma alteração no serviço de rede pode ser mais difícil de manter do que muitas alterações isoladas de marca. Registe o responsável, o limite de segurança afetado, os conflitos de integração, a cobertura de testes e os critérios de retirada de cada alteração a jusante.

Testes que começam demasiado tarde

A segurança e a compatibilidade devem partilhar um percurso de versões permanente. Iniciar uma campanha de testes improvisada após um aviso urgente a montante acrescenta atrasos evitáveis e incentiva exceções inseguras.

Um processo mantido conserva testes representativos de navegador, perfis, extensões, proxies, atualização, reversão e recuperação prontos para cada candidato. Um pequeno grupo anterior ao canal estável pode revelar alterações de compatibilidade antes da chegada da versão estável. A Google faz a mesma distinção nas suas orientações empresariais sobre atualizações: os testes faseados podem coexistir com atualizações automáticas, enquanto as atualizações pendentes continuam a exigir um reinício do navegador para entrarem em vigor.

Falhas de assinatura e publicação

Um binário compilado não constitui uma atualização pronta a lançar. As assinaturas da plataforma, a notarização quando aplicável, os metadados da atualização, os resumos criptográficos dos artefactos e os manifestos dos canais fazem parte do limite de segurança. Se um destes elementos estiver indisponível ou for incoerente, os utilizadores podem permanecer na versão antiga ou receber um artefacto não autorizado.

O desenho do atualizador do Chromium inclui a recuperação de um atualizador danificado ou demasiado antigo. Um navegador derivado precisa de provas equivalentes para a sua própria distribuição: artefactos autenticados, autorrecuperação do atualizador, recuperação de atualizações interrompidas e uma forma de interromper uma distribuição problemática sem perder a capacidade de enviar a correção seguinte.

Distribuições que nunca convergem

A distribuição faseada controla o risco de regressões, mas uma fase não é um destino. Cada distribuição precisa de critérios explícitos de promoção, um tempo máximo de permanência, um responsável por interrupções e visibilidade sobre a população que continua vulnerável.

A reversão exige o mesmo cuidado. Restaurar uma versão funcional mas vulnerável pode recuperar a disponibilidade enquanto reabre uma falha de segurança conhecida. O registo da versão deve identificar essa consequência e desencadear uma compilação de substituição, em vez de tratar silenciosamente a reversão como concluída.

Modos de falha que vale a pena testar

Um programa de atualização do navegador deve exercitar os percursos de falha antes de uma versão urgente depender deles:

• o aviso de segurança a montante chega fora do horário de trabalho;
• o ramo a montante muda durante a preparação de um candidato a jusante;
• uma alteração a jusante entra em conflito com uma correção de segurança;
• o candidato passa nos testes unitários, mas corrompe um perfil existente após o reinício;
• a assinatura funciona numa plataforma e falha noutra;
• os metadados de atualização e as versões dos artefactos não coincidem;
• a transferência é interrompida ou o armazenamento fica cheio;
• o navegador permanece aberto durante dias depois de a atualização ficar preparada;
• a interrupção de uma distribuição deixa alguns dispositivos em cada uma de duas versões vulneráveis;
• a recuperação do atualizador tem de funcionar a partir de uma versão instalada antiga; e
• a reversão recupera o arranque da aplicação, mas também restaura uma vulnerabilidade corrigida.

Estes testes ligam a segurança à recuperação. Publicar imediatamente sem verificar a integridade dos perfis pode causar perda de dados. Atrasar sem um processo limitado e observável prolonga a exposição. A qualidade exige um sistema de versões capaz de cumprir ambas as tarefas sob pressão.

Métricas que revelam a verdadeira janela de exposição

O NIST enquadra a gestão de correções como manutenção preventiva no SP 800-40 Rev. 4. Num navegador, as provas de manutenção úteis incluem:

• tempo entre a publicação a montante e a deteção a jusante;
• tempo entre a deteção e um candidato assinado;
• tempo entre a aprovação do candidato e a disponibilidade em cada canal;
• cobertura ativa da versão corrigida em intervalos definidos;
• mediana, percentil 95 e atraso máximo dos dispositivos;
• taxas de falha de transferência, verificação, instalação e reinício da atualização;
• número e antiguidade dos dispositivos com reinício pendente;
• estado de equivalência das correções para cada adaptação retroativa relevante;
• motivo, duração e população afetada de interrupções e reversões de distribuição; e
• êxito da recuperação do atualizador a partir da versão instalada suportada mais antiga.

Publique o método de medição juntamente com qualquer objetivo. Indique que evento inicia o relógio, que evento o termina, que plataformas estão incluídas, como são tratados os dispositivos sem ligação e se o número descreve um objetivo ou um resultado observado. Sem estas definições, uma afirmação como «atualização em 24 horas» pode significar a integração do código-fonte, a publicação de uma transferência ou a ativação em quase toda a frota.

Perguntas a fazer a um fornecedor de navegador baseado no Chromium

1. Que ramos estáveis e de suporte alargado são suportados e qual deles segue cada compilação instalada?
2. Quem monitoriza as atualizações de segurança a montante, incluindo versões não planeadas?
3. Quantos dias decorreram entre as últimas cinco versões de segurança a montante e os artefactos assinados a jusante?
4. Que percentagem de dispositivos suportados executava cada versão corrigida após 24, 48 e 72 horas?
5. Como são associadas as adaptações retroativas às correções a montante quando os números de versão diferem?
6. Que testes abrangem a sandbox, o ciclo de vida dos perfis, as extensões, os proxies, as atualizações e a recuperação?
7. Um atualizador que falhe consegue reparar-se sem instalar um artefacto não autenticado?
8. O que acontece a uma atualização de segurança pendente quando o navegador permanece aberto?
9. Como evita a reversão a reintrodução de uma vulnerabilidade conhecida?
10. Que resultados de atraso das atualizações são medidos e quais permanecem apenas objetivos de lançamento?

Um fornecedor pode, com razão, manter privados detalhes sensíveis de vulnerabilidades. Ainda assim, deve conseguir apresentar provas do processo, cobertura de versões, registos de versões assinadas, dados de falhas e métricas com âmbito claro.

O que a atualidade das atualizações não demonstra

Atualizações rápidas não demonstram que um navegador é seguro em todos os aspetos. Alterações a jusante podem introduzir vulnerabilidades. Extensões inseguras, um sistema operativo comprometido, controlos de assinatura fracos, importações maliciosas ou proteções de sandbox desativadas podem comprometer um motor atual. A atualidade das atualizações é uma camada necessária dentro de um modelo de segurança mais amplo.

O inverso também é verdadeiro: a marca, as definições de privacidade e as funções de isolamento de perfis não compensam um motor antigo. O conteúdo dos sites entra na superfície de ataque do Chromium antes de essas diferenças do produto poderem ajudar.