Chaves fracas da eMudhra: navegadores bloqueiam certificados, mas o terminal do Mac ainda tem brecha

Uma falha na criação de chaves de uma autoridade certificadora indiana fez Apple, Google e Mozilla agirem às pressas nos últimos dias. Oito certificados intermediários da eMudhra tinham chaves privadas tão fracas que podiam ser descobertas quase na hora. Com elas, alguém poderia emitir certificados que parecem válidos para qualquer site. Não há evidência de que isso tenha acontecido. Mesmo assim, a correção ainda não chegou a todo lugar: no Mac, algumas ferramentas de terminal continuam aceitando esses certificados.

O que deu errado

Segundo a Apple, seis das oito autoridades intermediárias emitem certificados TLS, usados em sites. As outras duas emitem certificados de assinatura de código, que os sistemas da Apple não aceitam.

O problema estava no tamanho das chaves. De acordo com o BleepingComputer, todas eram do tipo P-384, mas com valores abaixo de 256. Ou seja, bastava testar 256 números para achar cada uma. Uma delas, publicada no GitHub por um pesquisador conhecido como Flüpke, tinha valor 4. O The Register relata que o pesquisador Scott Helme achou valores como 56 e 115.

A eMudhra diz que as chaves foram criadas em 30 de abril de 2025, em equipamentos de segurança dedicados (HSM). Segundo a empresa, um erro de script numa etapa da cerimônia de geração, a de "embrulhar e desembrulhar" as chaves, produziu um segundo conjunto, fraco. Foi esse que acabou publicado. A análise completa ainda não saiu. Com isso, o erro passou cerca de 18 meses sem ser notado.

Como foi descoberto

O alerta veio de um pesquisador independente no sábado, 17 de outubro. O Google recebeu o relato às 18h05 UTC (15h05 em Brasília) e bloqueou as intermediárias no Chrome às 19h45 UTC, sem exigir atualização. A Mozilla recebeu o aviso às 20h06 UTC e concluiu o bloqueio no Firefox às 22h59 UTC.

No dia seguinte, a eMudhra revogou os oito certificados. Depois, Google e Mozilla foram além e decidiram deixar de confiar na raiz emSign ECC Root CA - G3. A Mozilla retirou a raiz no NSS 3.131.1. Já o Firefox 158.0.1 e as versões ESR saíram em 20 de outubro. Elas levaram o bloqueio a quem tinha configurações que impediam a atualização automática. No Chrome, segundo o Google, a retirada da raiz chega a todos os aparelhos na terça-feira (27). A previsão é a manhã, no horário do Pacífico.

O Google também afirma que nenhum certificado ligado às seis intermediárias de TLS apareceu nos registros públicos de transparência (CT) antes do bloqueio. Por isso, conclui a empresa, nenhum certificado fraudulento delas poderia ter sido usado contra o Chrome, que exige esse registro.

O que a Apple fez

A Apple publicou uma nota de suporte em 23 de outubro. Segundo a empresa, desde 19 de outubro seus aparelhos bloqueiam 12 certificados. Cada uma das seis intermediárias de TLS tem duas versões: uma ligada à raiz da eMudhra e outra com assinatura cruzada da Sectigo. O bloqueio chega por atualização automática de dados de configuração, sem instalar nada. Além disso, em 23 de outubro a Apple passou a bloquear também a raiz.

Há uma divergência de data. O BleepingComputer diz que a Apple acrescentou proteções em 22 de outubro. Já a nota da Apple fala em 19 de outubro, data repetida pela MacRumors.

A contagem também muda: a MacRumors fala em oito certificados, a Apple em 12. As duas batem, já que as seis autoridades de TLS têm duas versões cada.

A brecha que sobrou no Mac

Para quem usa Safari, Mail e apps comuns, a Apple diz que não é preciso fazer nada. O problema está no terminal. Ferramentas como curl, git, python3, ruby, perl e openssl consultam o arquivo /etc/ssl/cert.pem e não aplicam o bloqueio da Apple. Apps com lista própria de raízes também ficam de fora.

A Apple promete resolver isso numa atualização futura, sem data nem número de versão. Enquanto isso, sugere a administradores remover do arquivo a raiz emSign ECC Root CA - G3 e, se quiserem, a AAA Certificate Services, da Sectigo. Só a primeira não basta, já que as seis versões com assinatura cruzada continuam válidas pela raiz da Sectigo. A própria Apple avisa, no entanto, que a mudança pode quebrar o acesso a sites legítimos e que uma atualização do macOS pode desfazê-la.

Fora do mundo Apple, várias distribuições Linux e linguagens já atualizaram suas listas, segundo tabela do BleepingComputer. É o caso do Go 1.27.3 e do pacote certifi do Python. Na data da reportagem, Debian, FreeBSD, Node.js e Bun ainda apareciam como pendentes.

O que ainda não sabemos

• A análise completa da falha. A eMudhra atribui o problema a um erro de script, mas ainda não publicou o relatório final.
• Quantos sites serão afetados pela saída da raiz. A eMudhra fala em um único ecossistema de clientes atingido, nos EUA, cujos certificados estão sendo trocados.
• Quando sai a correção da Apple para as ferramentas de terminal.
• O que a Microsoft fez. Nenhuma das páginas lidas informa uma data de bloqueio no Windows.

Nossa leitura

A resposta dos navegadores foi rápida: menos de duas horas no Chrome, menos de três no Firefox e dois dias na Apple, pelas datas das próprias empresas. O ponto fraco está nas ferramentas que ninguém vê. Afinal, curl e git rodam em servidores, scripts e máquinas de desenvolvedores, e não consultam listas de bloqueio. Para quem administra Macs, vale seguir a nota da Apple até a atualização chegar.

O caso também mostra que uma autoridade aprovada em auditorias pode carregar um erro básico por um ano e meio. Para outro exemplo recente de falha com impacto amplo, veja as falhas críticas no PHP.