L’incident de sécurité Apple curl 12604

L’incident de sécurité Apple curl 12604

• Le 28 décembre 2023, le rapport de bug 12604 a été soumis sur le tracker d’issues de curl.
• Le problème portait le titre "flag –cacert behavior isn’t consistent between macOS and Linux" et signalait que le comportement du flag --cacert n’était pas cohérent entre macOS et Linux.
• Le rapporteur a montré que la version de curl intégrée à macOS se comportait différemment d’un binaire curl entièrement compilé en open source.

La version d’Apple vérifie en second le magasin système des CA

• L’option de ligne de commande --cacert permet d’indiquer à curl de ne faire confiance qu’à un ensemble spécifique de certificats d’autorité de certification (CA).
• Sur macOS, lorsqu’on utilise la version de curl fournie par Apple, si la validation échoue avec l’ensemble de certificats CA fourni, elle semble alors vérifier en second le magasin système des CA.
• Ce comportement n’est pas documenté et il est inattendu pour les utilisateurs.

Il s’agit d’un problème de sécurité

• Lorsqu’un utilisateur exécute une vérification avec un fichier de certificats CA spécifié, si le magasin système des CA contient un certificat capable de valider le serveur, l’opération n’échoue pas.
• Cela crée un problème de sécurité, car une vérification de certificat qui ne devrait pas passer finit par être acceptée.

Apple affirme qu’il n’y a pas de problème

• Le 8 mars 2024, l’équipe de sécurité produit d’Apple a répondu que la version d’OpenSSL (LibreSSL) 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 à l’aide du magasin de confiance système intégré, Apple ne considère pas cela comme un problème.

Pas d’accord

• À cause de cette fonctionnalité non documentée, la validation des certificats CA avec curl sur macOS n’est pas totalement fiable et ne correspond pas à la documentation.
• Cela peut semer la confusion chez les utilisateurs.
• Comme ce problème n’est pas une vulnérabilité de sécurité dans la version de curl que nous distribuons, aucun CVE n’est émis.
• Le problème ne se situe pas, à proprement parler, dans le code de curl, mais dans la version de LibreSSL fournie par Apple et utilisée pour compiler curl.

L’avis de GN⁺

• Cet incident souligne l’importance de la sécurité et de la fiabilité des logiciels. Lorsqu’un utilisateur souhaite n’utiliser que les certificats CA auxquels il fait explicitement confiance, le fait que le système accepte implicitement d’autres certificats peut soulever de sérieuses inquiétudes de sécurité.
• La réponse d’Apple montre qu’il existe un écart entre les critères de sécurité définis par l’entreprise elle-même et les attentes de la communauté open source. Cela peut lancer une discussion sur la manière dont utilisateurs et développeurs doivent percevoir et gérer la sécurité sur cette plateforme.
• Ce problème met en évidence les questions de dépendances et d’intégration qui peuvent survenir lors de l’utilisation de logiciels open source. Les développeurs doivent être conscients de ces différences lorsqu’ils utilisent des bibliothèques et des outils fournis par une plateforme spécifique, et y répondre de manière appropriée.
• D’autres projets offrant des fonctionnalités similaires incluent OpenSSL et GnuTLS, chacun avec sa propre philosophie de sécurité et sa propre approche d’implémentation. Les utilisateurs et les développeurs peuvent envisager ces alternatives.
• Lors de l’adoption d’une technologie, il faut examiner attentivement son modèle de sécurité et sa compatibilité entre plateformes. Cet incident montre que l’implémentation de LibreSSL par Apple fonctionne différemment du comportement standard de curl, ce qui souligne l’importance des choix technologiques.

[GN⁺]

Avis Hacker News

• Critique d’une certaine « fonctionnalité » d’Apple

  • Cette fonctionnalité peut ajouter des calculs inutiles ou casser le modèle de validation attendu.
  • Si un utilisateur veut fournir sa propre CA, c’est peut-être parce que la CA n’existe pas dans le bundle de l’OS ou parce qu’il veut valider une CA précise.
  • Ce comportement d’Apple ne correspond pas au résultat attendu.

• La politique d’Apple prime, indépendamment de l’intention du propriétaire de l’appareil Apple

  • Le fait que la politique d’Apple prime en ignorant ce que veut le « propriétaire » d’un appareil Apple est un phénomène courant, pas vraiment surprenant.

• Explication sur l’utilisation du magasin de CA de libcurl

  • Quand l’option CURLSSLOPT_NATIVE_CA est activée, libcurl utilise le magasin de CA par défaut du système d’exploitation pour effectuer la validation des certificats.
  • Si un fichier ou un répertoire de certificats CA est configuré, ils sont recherchés en plus du magasin de CA par défaut.
  • Combiné avec l’option --cacert, libcurl peut tenter de respecter les deux réglages, ce qui laisse entendre qu’ils peuvent être mutuellement exclusifs.

• Une situation similaire à l’affaire SQLite F_BARRIERFSYNC

  • Apple ne semble pas s’y intéresser.

• Nécessité pour Apple de corriger curl selon la remarque de Daniel

  • Si Daniel signale un problème dans curl, Apple doit le corriger.

• Problèmes de documentation de curl et faille de sécurité de libcurl

  • curl n’implémente pas directement tous les protocoles et prend en charge diverses bibliothèques.
  • L’inconvénient de cette approche est qu’il est difficile de garantir un comportement cohérent entre des backends indépendants.
  • libressl n’est pas une réimplémentation parfaite d’openssl et n’a aucune obligation d’en reproduire totalement l’API.
  • curl a deux options : abandonner la prise en charge de cette bibliothèque ou documenter le problème.
  • Pour éviter de casser le code utilisateur, il faudrait au minimum documenter le problème.
  • L’approche de libressl semble défaillante du point de vue de la sécurité, au point qu’il pourrait y avoir matière à ouvrir une CVE.

• Méfiance envers les logiciels inclus dans macOS

  • J’utilise MacPorts pour remplacer les outils inclus dans macOS (comme curl), car ils sont souvent obsolètes ou posent problème.

• Le comportement par défaut d’Apple pourrait être considéré comme une porte dérobée

  • Je ne dis pas que c’est intentionnel ou malveillant, mais cela peut, dans les faits, agir comme une porte dérobée.
  • Ajouter des clés au système d’authentification de l’utilisateur revient à ajouter une porte dérobée.

• Critique du fait qu’Apple ne se soucie pas de la sécurité des utilisateurs

  • Le comportement par défaut et le comportement alternatif sont différents.
  • Cela laisse entendre que l’équipe sécurité d’Apple a peut-être des problèmes de compréhension en lecture.