O git da Apple ainda confia nos certificados eMudhra comprometidos

Artigo original ↗ Discussão no Hacker News ↗

O tratamento da Apple para os certificados TLS eMudhra comprometidos está sendo criticado porque o macOS ainda distribui um bundle de CA em `/etc/ssl/cert.pem` que confia neles, deixando ferramentas de linha de comando como git, curl, Python e OpenSSL vulneráveis, mesmo que o Safari e outros apps de interface gráfica tenham sido protegidos rapidamente via o framework de confiança da Apple. Comentadores criticam a existência de dois armazenamentos de confiança separados no macOS, a orientação lenta e manual da Apple para remediação e o fato de que atualizações do sistema operacional podem desfazer silenciosamente as correções aplicadas pelo usuário. O incidente também destaca problemas mais profundos com o gerenciamento fragmentado de certificados em sistemas operacionais, contêineres e linguagens, e reacende pedidos por melhor revogação centralizada e design de trust store.

O que realmente está quebrado

  • O problema é mais amplo do que o Git: muitas ferramentas de linha de comando do macOS (git, curl, python3, ruby, perl, openssl, etc.) usam /etc/ssl/cert.pem, que ainda inclui raízes que permitem cadeias através de intermediários eMudhra comprometidos.
  • Apps de interface gráfica que usam a pilha Security/Keychain da Apple (Safari, apps típicos de Mac) foram atualizados rapidamente e não confiam na cadeia ruim.
  • O macOS efetivamente tem dois armazenamentos de confiança independentes: Keychain para APIs da Apple e /etc/ssl/cert.pem para ferramentas no estilo Unix, criando divergência e confusão.

Resposta da Apple e limitações

  • A Apple publicou um artigo oficial de suporte explicando como os usuários podem editar manualmente /etc/ssl/cert.pem para remover certas raízes (e, opcionalmente, raízes Sectigo relacionadas).
  • Vários comentaristas consideram isso inaceitável: os usuários precisam executar comandos de shell com sudo, as alterações são desfeitas por atualizações do sistema operacional (por exemplo, o macOS 27.2 restaurou os certificados ruins), e nenhuma correção automática rápida foi lançada.
  • Alguns especulam que a Apple trata as ferramentas CLI como de segunda classe e é lenta ou relutante em usar seus canais de atualização de segurança “background/rapid” para componentes Unix.

Workarounds e reações do ecossistema

  • Mitigações sugeridas:
    • Seguir manualmente as instruções da Apple para editar /etc/ssl/cert.pem.
    • Usar versões do curl e do OpenSSL do Homebrew ou do MacPorts, que trazem seus próprios bundles de CA; o Homebrew está atualizando o git para parar de usar o bundle do sistema.
    • Preferir SSH para remotos do Git em vez de HTTPS (embora o SSH tenha seus próprios problemas de confiança).
  • Scripts e one-liners para automatizar as instruções da Apple estão sendo compartilhados; alguns alertam contra normalizar o hábito de copiar e colar comandos aleatórios com sudo.

Impacto de segurança e debate sobre a gravidade

  • Muitos argumentam que isso representa um sério risco de MITM, especialmente em Wi‑Fi público ou roteadores comprometidos; ferramentas como o mitmproxy já suportam abusar da cadeia ruim.
  • Outros minimizam, dizendo que os atacantes precisam controlar redes locais e que a exploração em larga escala seria detectável agora que muitos dispositivos estão corrigidos.
  • Vários comentários observam problemas mais amplos de PKI: stores de CA fragmentados (por app, por container, por linguagem), mecanismos de revogação fracos ou não utilizados, e a dificuldade de desconfiança limpa de intermediários quando apenas raízes são empacotadas.

Meta: Apple, Linux e modelos de confiança

  • Alguns usam isso como motivo para preferir Linux; outros respondem que todas as plataformas já tiveram falhas graves de segurança.
  • Há críticas de que a Apple se vende como priorizando segurança, mas falhou em lançar uma correção centralizada e imediata para suas próprias ferramentas Unix.