Falha no macOS 27.2 deixa git e curl vulneráveis a ataque HTTPS

Segurança

Atualização do macOS 27.2 não corrige falha que expõe git e curl a ataques man-in-the-middle via certificados comprometidos.

Leia também: Jio IPO levanta US$ 3,2 bi e ações sobem 21% na estreia hoje

Ferramentas de desenvolvimento do macOS, como git, curl e python3, continuam confiando em certificados intermediários comprometidos da autoridade eMudhra, o que permite a interceptação e a manipulação de conexões HTTPS com serviços como GitHub, expondo credenciais e código-fonte a ataques man-in-the-middle mesmo após a atualização oficial do sistema para o macOS 27.2.

Atualização do macOS não corrige falha e desfaz correções manuais

A Apple foi informada sobre o incidente de segurança envolvendo a eMudhra em 17 de outubro. Desde então, os certificados intermediários comprometidos seguem instalados e confiados pelas ferramentas de linha de comando distribuídas com o macOS. Em vez de resolver o problema, o update macOS 27.2, lançado em 26 de outubro, manteve os certificados e ainda reverteu ajustes manuais feitos por usuários para mitigar o risco.

Em documentação técnica mantida pela comunidade, o alerta é direto: “macOS 27.2, released on 26th October, did not fix the issue and undid the workaround that users had applied by hand, leaving them vulnerable again”. Na prática, quem havia removido os certificados afetados do sistema precisou refazer o procedimento depois da atualização — e continuará tendo de repetir a operação até que a Apple publique um patch definitivo.

Enquanto isso, dezenas de outros projetos, muitos mantidos por voluntários, já liberaram correções, bloqueando os certificados da eMudhra em seus próprios pacotes ou ajustando cadeias de confiança internas. A discrepância entre o ritmo da comunidade e a resposta oficial da Apple aumenta a pressão por uma solução nativa no macOS.

Entenda o contexto

O problema está no fato de que certificados intermediários comprometidos permitem que um atacante em qualquer ponto do caminho de rede entre o desenvolvedor e o servidor HTTPS emita certificados aparentemente válidos para domínios de terceiros. “Anyone can intercept any HTTPS connection these tools make”, resume o texto técnico publicado pela comunidade de segurança.

Como git, curl, python3 e outras ferramentas de linha de comando do macOS usam um conjunto próprio de certificados confiáveis, separado do mecanismo de rede do Safari, elas continuam aceitando certificados assinados pela cadeia da eMudhra. Isso abre espaço para que um invasor se coloque entre o desenvolvedor e serviços como GitHub, GitLab ou servidores internos e, sem disparar alertas de certificado inválido, leia ou altere o tráfego.

Para o git, isso significa que operações de clone e pull via HTTPS podem entregar código escolhido pelo atacante, pushes podem ser modificados em trânsito e credenciais, como tokens de acesso ao GitHub, podem ser interceptadas. No caso de curl, downloads de dependências ou de artefatos de build ficam suscetíveis à substituição silenciosa por arquivos adulterados. Em ambientes de integração contínua e pipelines automatizados, o risco se estende à cadeia de suprimentos de software inteiro.

Como a falha afeta desenvolvedores no macOS

Na prática, qualquer desenvolvedor ou equipe que utilize git, curl ou python3 no macOS para se conectar a repositórios ou APIs via HTTPS está potencialmente vulnerável se o tráfego puder ser inspecionado em algum ponto da rota — por exemplo, em redes corporativas, Wi-Fi públicos, provedores de internet ou infraestruturas comprometidas.

Para demonstrar o impacto, a comunidade criou um servidor de teste que simula o GitHub usando um certificado emitido pelos intermediários da eMudhra. Ao rodar um comando de clonagem específico, o git do usuário é induzido a se conectar ao servidor falso. “A patched git will refuse with a certificate error. If the clone succeeds, you’ll see a README.md starting with INTERCEPTED”, descreve o guia. Se o clone ocorrer sem erro, o ambiente está vulnerável a ataques do tipo man-in-the-middle contra qualquer repositório HTTPS.

Procedimentos semelhantes existem para testar o curl e outras ferramentas distribuídas com o macOS. Em todos os casos, o sinal de proteção é o mesmo: a ferramenta deve recusar a conexão com um erro de certificado. Se a conexão é estabelecida normalmente, o certificado comprometido está sendo aceito.

A própria comunidade reforça que um atacante real não precisa do truque adicional usado na demonstração, como opções para redirecionar o domínio. Qualquer agente com capacidade de interceptar ou redirecionar o tráfego entre o desenvolvedor e o servidor legítimo pode explorar a brecha de forma transparente para o usuário.

O que a Apple já protegeu e o que falta fazer

Segundo o material técnico divulgado por pesquisadores, a proteção já foi aplicada a componentes que usam a estrutura de rede moderna da Apple. “Apple has already protected Safari and other apps built on its networking framework”, diz um dos trechos. Isso significa que, para o usuário comum navegando na web pelo Safari, o risco está mitigado.

O problema persiste, porém, nas ferramentas de desenvolvimento que não dependem diretamente dessa framework, mas sim de um arquivo de certificados em nível de sistema. Esses utilitários continuam confiando na cadeia da eMudhra e, portanto, vulneráveis. A orientação da comunidade é clara: “Apple needs to ship a fix for macOS developers as soon as possible, for example by removing the affected roots from /etc/ssl/cert.pem”.

Enquanto o patch oficial não chega, a recomendação é remover manualmente os certificados comprometidos do arquivo de certificados do sistema. “The affected roots can be removed by hand. The macOS workaround on the main page walks through the steps”, explica o guia mantido por Dennis Jackson e por colaboradores. A correção paliativa, no entanto, é frágil: “Apple’s guidance states that macOS updates may revert the fix, so developers need to repeat the checks above and the workaround after every update until Apple ships a fix”.

Na prática, desenvolvedores que dependem de macOS em ambientes críticos precisam incorporar à rotina de atualização do sistema a verificação dos certificados confiados por git, curl e demais ferramentas, refazendo o procedimento de remoção sempre que um update reinstalar os certificados da eMudhra.

Risco para infraestruturas de CI e cadeia de suprimentos

Equipes de segurança são orientadas a olhar além das máquinas de desenvolvedores individuais. O alerta se estende a servidores de build e runners de integração contínua que rodam macOS. A recomendação presente na documentação é que “security teams should also consider whether macOS runners are used in their CI or other build infrastructure and evaluate the supply chain risk”.

Se um pipeline de CI baseado em macOS utiliza git ou curl para buscar dependências, baixar imagens, sincronizar repositórios ou publicar artefatos, um ataque bem-sucedido pode contaminar toda a cadeia de geração de software, resultando em binários adulterados liberados para clientes finais ou incorporados a outros sistemas internos.

Setores que dependem fortemente da integridade do código, como empresas de tecnologia, bancos, fintechs e provedores de serviços digitais, são especialmente sensíveis a esse tipo de falha. Uma vez comprometida a cadeia de suprimentos de software, o prejuízo pode ser técnico, financeiro e reputacional.

O site que centraliza as informações sobre o caso foi publicado pelo pesquisador Dennis Jackson e recebe contribuições de outros especialistas e desenvolvedores. O conteúdo, incluindo scripts de teste e orientações de mitigação, tem código aberto e está sob licença Apache 2.0.

Até o momento, a expectativa da comunidade é que a Apple remova os certificados da eMudhra do conjunto confiado pelas ferramentas de desenvolvimento e distribua um patch de sistema em breve. Até lá, vale a orientação de reforçar monitoramento, revisar o uso de macOS em pipelines sensíveis e manter as correções manuais ativas, com checagens após cada nova atualização do sistema.