L’incident de sécurité Apple curl 12604

• Le curl fourni par Apple avec macOS traite l’option --cacert différemment d’un build open source, ce qui brise l’attente de validation TLS selon laquelle seules les autorités de certification spécifiées par l’utilisateur sont approuvées
• --cacert est une option qui impose de vérifier le certificat du serveur uniquement avec l’ensemble de certificats d’autorité de certification spécifié, et curl doit renvoyer une erreur si la vérification échoue
• Le curl fourni par Apple semble, même si la vérification avec l’autorité spécifiée échoue, consulter en plus le magasin de CA système ; ce comportement n’a pas été demandé et n’est pas documenté
• Apple Product Security a répondu que LibreSSL, l’OpenSSL d’Apple, utilise intentionnellement le magasin de confiance système intégré comme source de confiance par défaut, et qu’il ne s’agit donc pas d’un problème à corriger
• Comme il ne s’agit pas d’une vulnérabilité dans la distribution du projet curl, aucun CVE n’a été attribué, mais les résultats de validation des CA du curl fourni avec macOS peuvent différer de la documentation

---

Début de l’incident 12604

• Le 28 décembre 2023, le bugreport 12604 a été enregistré dans le suivi d’incidents de curl
• Le titre de l’incident était « flag --cacert behavior isn’t consistent between macOS and Linux », signalé par Yuedong Wu
• Même en exécutant la même version de curl sur la même machine macOS, le comportement différait entre le curl fourni par Apple et un binaire curl compilé depuis les sources open source

La garantie implicite attendue de --cacert

• L’option en ligne de commande --cacert de curl est le moyen de faire en sorte que curl fasse confiance uniquement à l’ensemble exact de certificats d’autorité de certification spécifié pour les transferts suivants
• Si le serveur TLS ne présente pas un certificat vérifiable avec cet ensemble de certificats, curl doit échouer et renvoyer une erreur
• Cette option a été ajoutée à curl en décembre 2000 et sert à vérifier que l’on communique bien avec un serveur connu et de confiance
• Elle touche donc directement à l’un des rôles fondamentaux que TLS est censé assurer

Le comportement atypique du curl fourni avec macOS

• Le curl pour macOS fourni par Apple semble, lors de l’utilisation de --cacert, consulter en plus le magasin de CA système si la vérification avec l’ensemble de certificats spécifié échoue
• Cette vérification de secours n’est pas le comportement demandé par l’utilisateur et n’apparaît pas dans la documentation, ce qui la rend difficile à prévoir
• Même si l’utilisateur tente de valider avec un fichier de certificats CA réduit et dédié, l’échec ne se produit pas si le magasin de CA système contient un certificat capable de valider le serveur
• En conséquence, une validation de certificat qui ne devrait pas réussir peut réussir, ce qui est considéré comme un problème de sécurité

La réponse d’Apple Product Security

• Le 29 décembre 2023 à 08:30 UTC, un e-mail de signalement de problème de sécurité a été transmis à Apple Product Security
• Apple Product Security a répondu le 8 mars 2024
• La réponse d’Apple se résume en deux points
  • LibreSSL, l’OpenSSL d’Apple, utilise intentionnellement le magasin de confiance système intégré comme source de confiance par défaut
  • Comme le certificat du serveur peut être validé avec succès via le magasin de confiance système intégré, Apple ne considère pas qu’il s’agisse d’un problème à traiter sur ses plateformes
• Apple a clos ce cas

L’évaluation du projet curl et l’impact pour les utilisateurs

• Cette fonctionnalité non documentée de macOS rend la validation des certificats CA de curl incohérente avec la documentation
• Les utilisateurs s’attendent à ce que seul l’ensemble de certificats CA spécifié via --cacert soit utilisé, mais le curl fourni par Apple ne se comporte pas ainsi
• Ce problème n’est pas une vulnérabilité de sécurité dans la version de curl distribuée par le projet curl
  • Le projet curl n’a pas attribué de CVE pour ce problème
  • Le problème ne provient pas du code de curl lui-même, mais de la version de LibreSSL qu’Apple fournit sur sa plateforme et utilise pour ses builds de curl
• Lorsqu’on utilise le curl fourni par Apple sur macOS, les résultats de validation basés sur --cacert peuvent différer de ceux d’un build open source de curl

[GN⁺]

Avis sur Hacker News

• Ce comportement est complètement absurde. Si je spécifie moi-même une CA, c’est pour l’une de deux raisons : soit ma CA n’est pas dans le bundle du système d’exploitation, soit je veux valider uniquement contre une CA précise.
  Autrement dit, cette « fonctionnalité » d’Apple ajoute soit des calculs inutiles, soit casse le modèle de validation attendu. Aucun des deux n’est un résultat souhaitable.

  • Petite correction : quand la première vérification échoue, il y a un repli vers le magasin de CA d’Apple. Donc cela n’ajoutera probablement pas de calculs inutiles.
    Je suis tout de même d’accord pour dire que c’est un mauvais comportement, car ce n’est pas le résultat attendu. Vu qu’Apple préfère généralement les changements qui cassent la rétrocompatibilité, et que cette fonctionnalité a été ajoutée à curl, il semble y avoir une raison qu’Apple n’a pas révélée. Peut-être que cela sert à des outils de diagnostic développeur ou à la validation de l’App Store.
  • On dit qu’il ne faut pas attribuer à la malveillance ce qui s’explique par la bêtise, mais il faut être particulièrement prudent quand un acteur malveillant utilise le rasoir de Hanlon comme ligne de défense.

• Malheureusement, ce comportement où la politique d’Apple prime toujours, quoi que le « propriétaire » d’un appareil Apple essaie de faire, n’est pas surprenant ; c’est quelque chose auquel il faut toujours s’attendre chez Apple.

  • C’est pour ça que j’ai arrêté d’utiliser Apple. Les appareils semblent vraiment bien conçus et le système d’exploitation est soigné, mais le fait de vous enfermer dans leur façon de faire et leur écosystème, et même de bloquer l’accès à votre propre matériel, n’est pas compatible avec une vie de hacker au sens HN du terme.
    Du moins pas pour cette partie de ma vie numérique, et vu le prix, c’est aussi difficile à justifier comme appareil secondaire posé à côté. J’ai souvent envisagé d’essayer des produits Apple, récemment encore avec le casque AR, mais jusqu’ici ils m’ont semblé trop hostiles aux développeurs et aux bricoleurs.
  • Si vous exécutez le curl open source, vous obtenez le comportement souhaité.
  • Malheureusement, il y aura toujours des gens pour surinterpréter des décisions techniques de bas niveau afin de « prouver » leurs préjugés.
    Penser qu’une entreprise aussi grande qu’Apple a pris ce genre de décision au service d’une vision plus large consistant à « posséder les appareils des utilisateurs », c’est attribuer à Apple un niveau d’organisation et de coordination énorme. Un niveau dont je n’ai jamais entendu parler même dans des organisations dix fois plus petites qu’Apple. Mais bon, c’est Apple, n’est-ce pas !?
  • Le propriétaire, c’est Apple ; vous n’êtes que l’utilisateur ;)

• Peut-être que c’est Apple qui active ceci ?[0] C’est moi qui souligne.
  CURLSSLOPT_NATIVE_CA
  Indique à libcurl d’utiliser le magasin de CA par défaut du système d’exploitation pour la vérification des certificats. Si cette option est définie en même temps qu’un fichier de certificats CA ou un répertoire, ces certificats seront aussi recherchés pendant la vérification, en plus du magasin de CA par défaut.
  Quand --cacert est combiné avec cette option, libcurl semble vouloir respecter les deux. Les deux ne devraient-ils pas être mutuellement exclusifs ?

  • Non, ce n’est pas le cas ici. Le binaire curl sait comment il doit appeler la bibliothèque libcurl.

• C’est une porte dérobée.
  Je ne dis pas que c’est intentionnel ou malveillant. Mais dans les faits, c’est bien une porte dérobée. Si vous commencez à ajouter des clés au système de confiance de l’utilisateur, vous avez ajouté une porte dérobée.

  • Cela ressemble exactement au genre de chose que la NSA pourrait faire pression sur une grande entreprise tech américaine pour qu’elle fasse.

• Le comportement par défaut est suspect, mais je ne suis pas entièrement d’accord avec cette évaluation. En réalité, c’est un problème de documentation de curl.
  curl est une bibliothèque multiprotocole : elle n’implémente pas elle-même tous les protocoles, et s’appuie dans la plupart des cas sur des « backends » de dépendances transitives qui se chargent de l’interprétation bas niveau des bits. Pour certains protocoles, elle inclut, pour de bonnes raisons, la prise en charge de plusieurs bibliothèques alternatives.
  L’inconvénient de cette approche, c’est qu’il est difficile, voire impossible, de garantir un comportement commun entre des backends indépendants. Ils peuvent ne pas proposer toutes les mêmes fonctionnalités, leurs API peuvent être incomplètes, ou, comme ici, ne pas fournir de moyen de modifier une partie du comportement par défaut. LibreSSL n’est pas une réimplémentation bit à bit d’OpenSSL et n’a pas l’obligation d’imiter parfaitement son API.
  Dans ce genre de cas, si l’upstream refuse de corriger, curl a deux options : abandonner la prise en charge de cette bibliothèque, ou documenter ce comportement particulier. La première option risquant de casser le code des utilisateurs, il faut au moins faire la seconde.
  Cela dit, je suis d’accord avec l’idée générale selon laquelle cette approche constitue un défaut du point de vue de la sécurité de LibreSSL, et il y a peut-être matière à ouvrir une CVE. Mais la cible devrait être LibreSSL.

  • Si la cause racine est dans la bibliothèque SSL du système, je ne comprends pas bien comment compiler curl depuis les sources permet de contourner ce problème.

• Cela me rappelle l’affaire F_BARRIERFSYNC de SQLite.
  Ils s’en fichent, tout simplement.
  https://bonsaidb.io/blog/acid-on-apple/

  • Cela me rappelle une ancienne fois où Apple avait effectivement cassé l’un des vieux outils Unix qu’ils livrent, en y bricolant maladroitement une option.
    Leur attitude en matière de maintenance est encore deux crans en dessous du gars de Debian qui a cassé OpenSSL.

• Si Daniel dit que votre curl est cassé, corrigez-le, Apple. C’est aussi simple que ça.

  • Daniel peut aussi se tromper. Même à propos de curl.
    Ici, après deux minutes de vérification, il a probablement raison, mais « c’est Daniel donc il a raison » est le pire des raisonnements.
    Cela me rappelle de vieilles discussions autour de l’histoire de C, en particulier des « contributions » d’Eric S. Raymond : https://scienceblogs.com/deltoid/2011/10/14/dennis-ritchie-h...

• Merci pour l’avertissement. Pour info, j’utilise MacPorts pour remplacer une bonne partie des outils fournis avec macOS. curl en fait partie.
  Les outils fournis sont généralement anciens ou cassés d’une autre manière. J’ai perdu depuis longtemps toute confiance dans les logiciels intégrés par Apple.

• Je me demande si Apple ne dépend pas de ce comportement pour quelque chose d’important.

  • Je ne sais pas si c’est sarcastique, mais c’est clairement très important.
    Il est tout à fait raisonnable que quelqu’un écrive un script pour n’utiliser qu’une CA privée interne. En exécutant cette commande, vous savez que vous ne communiquez qu’avec des ressources internes de l’entreprise, puisqu’il s’agit de la CA interne de l’entreprise.
    Or Apple y ajoute une porte dérobée aussi large que la validation de domaine.
    Plus encore, il est tout à fait valable d’utiliser un nom factice et de vérifier que l’on se connecte au serveur de l’entreprise simplement parce que le certificat est signé par la CA de l’entreprise. Apple casse cette hypothèse parfaitement raisonnable et crée ainsi une faille de sécurité. Ce n’est pas bon.
  • Cela pourrait être pour faciliter l’interception TLS en entreprise ou par des gouvernements.
  • C’est soit d’une stupidité extrême, soit malveillant.

• Voilà donc à quel point Apple se soucie de la sécurité des utilisateurs.