macOS continue de faire confiance aux certificats eMudhra compromis
Sommaire
En bref
- Apple a été informée le 17 octobre de certificats intermédiaires eMudhra compromis (clés faibles générées par erreur).
- Au 28 octobre, git, curl et python3 livrés avec macOS continuent de les accepter, exposant les clones HTTPS et les credentials aux interceptions.
- macOS 27.2 (26 octobre) n'a apporté aucun correctif et a même annulé les contournements manuels appliqués par les utilisateurs.
- Des dizaines de projets open source ont livré des patches en quelques jours ; Apple propose pour l'instant un contournement manuel via /etc/ssl/cert.pem, avec le risque que les mises à jour futures le révertissent.
Ce que dit la source
Apple a échoué à révoque les certificats intermédiaires eMudhra compromis issus de clés mal générées. La faille, découverte mi-octobre, permet à quiconque en position d'interception réseau (redirection DNS, WiFi public, operator national) de intercepter et modifier le trafic HTTPS des outils de développement macOS (git, curl, python3), incluant le vol de tokens GitHub. Apple a protégé Safari en utilisant son Security.framework propriétaire, mais les outils en ligne de commande restent vulnérables car ils font confiance au magasin de certificats du système /etc/ssl/cert.pem, qui n'a pas été mis à jour. Le problème s'est aggravé : macOS 27.2 (sortie le 26 octobre) a réintroduit les certificats malveillants, revertant les mitigations manuelles que les développeurs avaient appliquées.
- Les outils affectés, git, curl, python3, et autres utilitaires embarqués, acceptent les certificats intermédiaires compromis, exposant chaque clone ou pull HTTPS à une interception transparente de code malveillant ou de credentials.
- La vulnérabilité est contrôlable via réseau par quiconque peut rediriger le trafic : opérateur réseau, administrateur WiFi public, ou attaquant sur le même segment, sans compromission préalable du système.
- Apple n'a pas patché ces outils au niveau OS ; sa réponse officielle (support.apple.com/149555) se limite à un contournement manuel via modification de /etc/ssl/cert.pem, avec avertissement que les futures updates macOS peuvent annuler la correction.
- Plusieurs dizaines de projets open source (npm, OpenSSL, distributions Linux, etc.) ont livré des correctifs en quelques jours ; le délai d'Apple reste disproportionné.
- L'architecture de macOS sépare les vérificateurs de certificats : Safari utilise Security.framework/trustd (protégé), tandis que les CLIs font confiance au fichier cert.pem plat, qui ne peut pas exprimer des révocations granulaires.
Dans les commentaires
Débat partage : la sévérité technique est reconnue et légitime (il y a vraiment une vulnérabilité d'interception), mais la probabilité réelle d'exploitation et l'ordre des priorités divisent les commentateurs. Certains soulignent l'inaction inacceptable d'Apple ; d'autres minimisent le risque pratique en rappelant les prérequis de positionnement réseau ; un débat secondaire porte sur la fragmentation du système de certificats de confiance macOS et ses limites architecturales.
- Plusieurs commentateurs contestent l'urgence : bien que la faille soit réelle, ils notent que faire une MITM efficace exige déjà une position réseau compromise (routeur, WiFi public, niveau opérateur), pas juste l'accès aux certificats ; le risque décalé du jour 0 entre la découverte et le déploiement reste limité en pratique.
- L'architecture de macOS sépare les mécanismes : Safari utilise Security.framework (sécurisé, patché), tandis que les outils CLI se fient à /etc/ssl/cert.pem statique. Plusieurs commentateurs soulignent que cette séparation est une faiblesse fondamentale ; certains suggèrent qu'Apple route les CLIs par le même vérificateur que Safari.
- Un débat sur les limites du modèle de révocation : CRL et OCSP ont échoué en tant que standards pratiques ; Apple aurait pu implémenter une révocation rapide au niveau OS (comme Windows Update le fait), mais préfère les mises à jour monolithiques.
- Un commentateur soulève une question de fond : pourquoi conserver des centaines d'autorités de certificats racines quand un compromis sur une seule peut briser la chaîne entière ? Aucune réponse constructive n'émerge du fil.
- Tensions sur la responsabilité : un commentateur critique implicitement Apple pour avoir confié l'OS à une structure centralisée (délégation totale d'autorité), tandis que d'autres considèrent ce reproche comme hors de propos dans un contexte technique précis.
Notre lecture
C'est une faille réelle, mais l'ordre de bataille d'Apple reste disproportionné. La vulnérabilité existe, elle est simple à démontrer (tests fournis dans l'article), et l'inaction sur deux semaines après notification est inacceptable pour un outil de développement. Cependant, l'exploitation concrète exige une position réseau précise (pas une simple chaîne de certificats), ce qui limite la portée aux environnements déjà compromis. Pour les équipes : contrôler le problème maintenant via le contournement macOS officiel (ou MacPorts) ; cette faille ne justifie pas une migration d'OS urgent, mais elle montre qu'Apple traite les outils CLI comme une sous-catégorie dans sa stratégie de sécurité (Safari patché rapidement, CLIs ignorées). À surveiller pour du contexte sur la capacité de réponse d'Apple face aux incidents de confiance système.