Nota do tradutor: para conveniência dos leitores, as datas estão em horário de Moscovo.
Recentemente, deixamos passar o momento de expiração de um dos certificados utilizados para assinar os complementos. Isso levou à desativação dos complementos para os usuários. Agora que, na maior parte, o problema foi corrigido, gostaria de compartilhar os detalhes do que ocorreu e do trabalho realizado.
Contexto: complementos e assinaturas
Os complementos instalados devem ter uma assinatura digital, que protege os usuários contra complementos maliciosos, e exige a verificação mínima dos complementos pelos funcionários da Mozilla. Introduzimos essa exigência em 2015, pois enfrentávamos sérios problemas com complementos maliciosos.
Como isso funciona: cada cópia do Firefox contém um "certificado raiz". A chave desse "raiz" é armazenada em um módulo de segurança de hardware (HSM), que não tem acesso à rede. A cada poucos anos, essa chave assina um novo "certificado intermediário", que é utilizado na assinatura dos complementos. Quando um desenvolvedor envia um complemento, criamos um "certificado final" temporário e o assinamos, usando o certificado intermediário. Em seguida, o próprio complemento é assinado com o certificado final. Esquematicamente isso se parece com isso.
Observe: cada certificado possui um "sujeito" (a quem o certificado foi emitido) e um "emitente" (quem emitiu o certificado). No caso do certificado raiz, o "sujeito" = "emitente", mas para outros certificados, o emitente do certificado é o sujeito do certificado superior do qual ele foi assinado.
Ponto importante: cada complemento é assinado com um certificado final único, mas quase sempre esses certificados finais são assinados pelo mesmo certificado intermediário.
Nota do autor: a exceção são os complementos muito antigos. Naquele tempo, usavam-se vários certificados intermediários.
Este certificado intermediário causou problemas: cada certificado é válido por um determinado período. Antes ou depois desse período, o certificado se torna inválido, e o navegador não usará complementos assinados por esse certificado. Infelizmente, a validade do certificado intermediário expirou em 4 de maio às 4 horas da manhã.
As consequências não se manifestaram imediatamente. O Firefox verifica as assinaturas dos complementos instalados não constantemente, mas aproximadamente a cada 24 horas, com o horário da verificação sendo individual para cada usuário. Como resultado, algumas pessoas enfrentaram problemas imediatamente, enquanto outras muito mais tarde. Fomos informados do problema aproximadamente no momento em que o certificado expirou e começamos a procurar uma solução.
Minimizando os danos
Assim que entendemos o que aconteceu, tentamos evitar que a situação piorasse.
Primeiro, paramos de aceitar e assinar novos complementos. Não faz sentido usar um certificado expirado para isso. Olhando para trás, diria que poderíamos ter deixado tudo como estava. Atualmente, a aceitação de complementos foi reiniciada.
Em segundo lugar, enviamos imediatamente uma correção que impediu a verificação diária das assinaturas. Dessa forma, conseguimos salvar os usuários cujo navegador ainda não havia verificado os complementos nas últimas 24 horas. Atualmente, essa correção foi revogada, pois não há mais necessidade dela.
Trabalho paralelo
Teoricamente, a solução do problema parece simples: criamos um novo certificado intermediário válido e re-assinamos cada complemento. Infelizmente, isso não funcionará:
- não conseguimos re-assinar rapidamente 15 mil complementos de uma só vez, o sistema não está preparado para essa carga
- depois que assinarmos os complementos, as versões atualizadas precisam ser entregues aos usuários. A maioria dos complementos é instalada a partir dos servidores da Mozilla, portanto, nas próximas 24 horas o Firefox encontrará atualizações, mas alguns desenvolvedores distribuem complementos assinados por canais de terceiros, então os usuários teriam que atualizar esses complementos manualmente
Em vez disso, tentamos desenvolver uma correção que chegasse a todos os usuários, sem exigir (ou quase sem exigir) ações de sua parte.
Chegamos rapidamente a duas estratégias principais, que utilizamos em paralelo:
- Atualizar o Firefox para alterar o período de validade do certificado. Isso fará com que as extensões existentes funcionem novamente, mas exigirá a liberação e entrega de uma nova versão do Firefox.
- Criar um certificado válido e, de alguma forma, convencer o Firefox a aceitá-lo em vez do existente, que está expirado.
Decidimos primeiro usar a primeira opção, que parecia bastante funcional. No final do dia, lançamos também a segunda correção (novo certificado), que discutiremos a seguir.
Substituição do certificado
Como mencionei acima, era necessário:
- criar um novo certificado válido
- instalá-lo remotamente no Firefox
Para entender por que isso funcionará, vamos analisar mais detalhadamente o processo de verificação da extensão. A própria extensão é fornecida como um conjunto de arquivos, incluindo a cadeia de certificados utilizados para assinatura. Como resultado, a extensão pode ser verificada se o navegador conhece o certificado raiz, que é embutido no Firefox durante a construção. No entanto, como já sabemos, o certificado intermediário está expirado, portanto, a verificação da extensão é impossível.
Quando o Firefox tenta verificar a extensão, ele não se limita a usar os certificados contidos dentro da própria extensão. Em vez disso, o navegador tenta criar uma cadeia de certificados válida, começando pelo certificado final e continuando até chegar ao raiz. No primeiro nível, começamos com o certificado final e então encontramos o certificado cujo sujeito é o editor do certificado final (ou seja, o certificado intermediário). Normalmente, esse certificado intermediário é fornecido com a extensão, mas qualquer certificado do repositório do navegador também pode desempenhar esse papel. Se conseguirmos adicionar remotamente um novo certificado válido ao repositório de certificados, o Firefox tentará usá-lo. A situação antes e depois da instalação do novo certificado.
Após a instalação do novo certificado, o Firefox terá duas opções ao verificar a cadeia de certificados: usar o antigo certificado inválido (que não funcionará) ou o novo certificado válido (que funcionará). É importante que o novo certificado contenha o mesmo nome de sujeito e chave pública que o antigo, portanto, sua assinatura no certificado final será válida. O Firefox é inteligente o suficiente para tentar ambas as opções até encontrar uma que funcione, então os complementos serão verificados novamente. Observe que esta é a mesma lógica que usamos para verificar certificados TLS.
Nota do autor: leitores familiarizados com WebPKI notarão que os certificados cruzados funcionam exatamente da mesma forma.
O mais notável sobre essa correção é que ela não requer a re-assinatura dos complementos existentes. Assim que o navegador receber o novo certificado, todos os complementos voltarão a funcionar. A complexidade permanece em entregar o novo certificado aos usuários (automaticamente e remotamente), além de fazer o Firefox re-verificar os complementos desativados.
Normandy e o sistema de pesquisas
Por ironia do destino, essa questão é resolvida por um complemento especial chamado 'sistêmico'. Para conduzir pesquisas, desenvolvemos um sistema chamado Normandy, que entrega pesquisas aos usuários. Essas pesquisas são executadas automaticamente no navegador e têm acesso ampliado às APIs internas do Firefox. As pesquisas podem adicionar novos certificados ao armazenamento de certificados.
Nota do autor: não adicionamos o certificado com privilégios especiais; ele é assinado pelo certificado raiz, então o Firefox confia nele. Estamos apenas adicionando-o ao pool de certificados que podem ser usados pelo navegador.
Portanto, a solução é criar uma pesquisa:
- instalando para os usuários o novo certificado que criamos
- forçando o navegador a re-verificar os complementos desativados para que funcionem novamente
"Mas espere," você dirá, "os complementos não estão funcionando, como iniciar um complemento sistêmico?" Vamos assiná-lo com o novo certificado!
Juntando tudo... por que leva tanto tempo?
Então, o plano: lançar um novo certificado para substituir o antigo, criar um complemento do sistema e instalá-lo para os usuários através do Normandy. Os problemas, conforme mencionei, começaram no dia 4 de maio às 4:00, e já às 12:44 do mesmo dia, em menos de 9 horas, enviamos a correção ao Normandy. Levou mais 6-12 horas para que chegasse a todos os usuários. Já não está mal, mas os usuários no Twitter estão perguntando por que não conseguimos agir mais rápido.
Primeiro, levou tempo para emitir um novo certificado intermediário. Como mencionei acima, a chave do certificado raiz é armazenada de forma autônoma em um módulo de segurança de hardware. Isso é bom em termos de segurança, pois a raiz é usada muito raramente e deve ser bem protegida, mas é um pouco inconveniente quando é necessário assinar um novo certificado de emergência. Um dos nossos engenheiros teve que ir ao armazenamento HSM. Em seguida, houve tentativas malsucedidas de emitir o certificado correto, e cada tentativa custou uma ou duas horas gastas em testes.
Em segundo lugar, o desenvolvimento do complemento do sistema levou algum tempo. Conceitualmente é muito simples, mas até mesmo programas simples exigem atenção. Queríamos garantir que não piorássemos a situação. O complemento precisava ser testado antes de ser enviado aos usuários. Além disso, o complemento deve ser assinado, mas nosso sistema de assinatura de complementos estava desligado, tivemos que procurar uma solução alternativa.
Finalmente, depois de preparar o complemento para envio, foi necessário tempo para a implantação. O navegador verifica atualizações do Normandy a cada 6 horas. Nem todos os computadores estão sempre ligados e conectados à internet, então leva tempo para que a correção se espalhe entre os usuários.
Etapas finais
O complemento deve corrigir o problema para a maioria dos usuários, mas não está disponível para todos. Alguns usuários exigem uma abordagem especial:
- usuários que desativaram complementos ou telemetria
- usuários da versão Android (Fennec), onde os complementos não são suportados
- usuários de versões personalizadas do Firefox ESR em empresas, onde não é possível ativar a telemetria
- usuários atrás de proxies MitM, já que nosso sistema de instalação de complementos usa vinculação de chaves (key pinning), que não funciona com esses proxies
- usuários de versões antigas do Firefox que não suportam pesquisas
Não podemos fazer nada em relação à última categoria de usuários — eles ainda precisam atualizar para uma nova versão do Firefox, pois as versões antigas têm vulnerabilidades graves e não corrigidas. Sabemos que algumas pessoas permanecem em versões antigas do Firefox porque desejam rodar complementos antigos, mas muitos dos complementos antigos já foram portados para as novas versões do navegador. Para os demais usuários, desenvolvemos um patch que instalará um novo certificado. Ele foi lançado como uma versão de correção de bugs (nota do tradutor: Firefox 66.0.5), portanto, as pessoas o receberão — provavelmente já o receberam — pelo canal normal de atualização. Se você estiver usando uma versão personalizada do Firefox ESR, entre em contato com seu mantenedor.
Compreendemos que tudo isso não é perfeito. Em alguns casos, os usuários perderam dados de complementos (por exemplo, os dados do complemento Multi-Account Containers).
Esse efeito colateral não pôde ser evitado, mas acreditamos que, a curto prazo, escolhemos a melhor solução para a maioria dos usuários. A longo prazo, buscaremos outras abordagens arquitetônicas mais sofisticadas.
Lições
Primeiro, nossa equipe fez um trabalho incrível, criando e enviando uma correção em menos de 12 horas após a descoberta do problema. Como alguém que esteve presente nas reuniões, posso dizer que, nessa situação complexa, as pessoas trabalharam muito arduamente e pouco tempo foi perdido em vão.
É claro que tudo isso não deveria ter acontecido. É evidente que devemos ajustar nossos processos para reduzir a probabilidade de incidentes semelhantes e facilitar a correção das consequências.
Na próxima semana, publicaremos o relatórios pós-morte oficial e uma lista de alterações que pretendemos implementar. Por enquanto, quero compartilhar meus pensamentos. Em primeiro lugar, deve haver uma maneira melhor de monitorar o estado do que pode ser uma bomba-relógio. Precisamos ter certeza de que não estaremos em uma situação onde uma delas detone inesperadamente. Estamos ainda trabalhando nos detalhes, mas, no mínimo, precisamos fazer um inventário de todas essas coisas.
Em segundo lugar, precisamos de um mecanismo para entregas rápidas de atualizações aos usuários, mesmo quando — especialmente quando — tudo mais estiver fora do ar. Foi ótimo que conseguimos usar o sistema de 'pesquisas', mas este é uma ferramenta imperfeita e possui alguns efeitos colaterais indesejados. Em particular, sabemos que muitos usuários têm atualizações automáticas habilitadas, mas prefeririam não participar de pesquisas (confesso que eu também as desativei!). Ao mesmo tempo, precisamos de uma maneira de enviar atualizações aos usuários, mas, qualquer que seja a implementação técnica interna, os usuários devem poder se inscrever para atualizações (incluindo correções urgentes), mas optar por não receber todo o resto. Além disso, o canal de atualização deve ser mais responsivo do que é atualmente. Mesmo em 6 de maio, ainda havia usuários que não tinham aproveitado nem correções nem a nova versão. Já trabalhamos nessa questão, mas o que aconteceu mostrou quão importante ela é.
Finalmente, vamos revisar a arquitetura de segurança das extensões para garantir que ela forneça um nível adequado de segurança com o mínimo risco de quebrar algo.
Na próxima semana, vamos considerar os resultados de uma análise mais aprofundada do que aconteceu, mas, enquanto isso, ficarei feliz em responder a perguntas por e-mail: ekr-blog@mozilla.com
Fonte: linux.org.ru
