webleads-tracker

Bug dans l’implémentation SSL d’Apple : une erreur de débutant ?

Une faille critique vient d’être corrigée dans les systèmes d’exploitation de la société Apple. Elle permet à un attaquant d’intercepter toutes les communications chiffrées, sans se faire détecter, et ce depuis plus de deux ans.

S’agit-il vraiment d’une erreur de débutant, comme on peut le lire un peu partout ? Et comment peut-on se prémunir contre ce type d’erreur ? Nous avons analysé la vulnérabilité et nous vous proposons des éléments de réponse.

Si vous avez un peu suivi l’actualité le weekend dernier, vous avez pu lire qu’une faille critique vient d’être corrigée dans iOS, le système d’exploitation des iPhones et iPads. Elle affecte également Mac OSX 10.9 (Mavericks) – pour lequel Apple n’a pas encore publié de correctif. Avant d’aller plus loin dans notre analyse, nous vous encourageons à mettre à jour vos systèmes iOS au plus vite. Pour ceux qui utilisent OSX 10.9, Stefan Esser a publié un correctif non officiel, que vous pouvez appliquer temporairement pour vous protéger en attendant la sortie d’OSX 10.9.2. mise à jour : OSX 10.9.2 est disponible et corrige cette faille.

Cela étant posé, quel est l’impact de cette vulnérabilité, et s’agit-il réellement d’une erreur triviale ?

SSL, TLS et l’homme du milieu

La faille identifiée permet à une personne mal intentionnée d’intercepter et de modifier les communications chiffrées  entre un client vulnérable et un serveur, sans que le client ne puisse s’apercevoir de l’attaque. Elle semble présente dans le code d’une bibliothèque d’iOS depuis la sortie de la version 6.0, en septembre 2012, et affecte iOS 7 et Mac OSX 10.9. Il est donc théoriquement possible, et ce depuis 29 mois, d’écouter tout ce que les utilisateurs d’iPhone envoient – que leurs communications soient chiffrées ou non.

Une faille très commentée

Contrairement à de nombreuses autres failles touchant à la cryptographie, celle-ci a largement été reprise par de nombreux sites. Cette importante couverture est en grande partie due au fait que, pour une fois, la cause du problème est assez simple à comprendre, et donc à expliquer au lecteur un peu technophile. En effet, si on se penche sur le code vulnérable (open source, disponible sur le site d’Apple), on cerne assez vite le problème (pardon à ceux qui sont allergiques au code, ça ne prendra que quelques lignes que vous pouvez ignorer) :

 Le goto ligne 632 est suivi dans tous les cas, tous les tests suivant

Figure 1 : Le goto ligne 632 est suivi dans tous les cas, tous les tests suivants dans le code sont ignorés.

Chacun y va donc de son analyse, et nombreux sont ceux qui prennent des airs outrés.  Le site Mac Génération évoque ainsi « une erreur de programmation à peine croyable », quand le site macplus.net parle « [d’]une erreur de codeur débutant qui prêterait presqu’à rire si les conséquences possibles pouvaient ne pas être aussi graves ». Sur Twitter, les moqueries vont bon train.

Mais est-on réellement en face d’un problème trivial ?

La critique est aisée, la crypto est difficile

Bien sûr, une fois qu’on a repéré le bug, il est très simple à corriger. Il choque les gens parce qu’ils peuvent aisément mettre le doigt sur le problème, et qu’il implique une construction couramment décriée, le goto (et tout aussi couramment utilisée dans le code bas niveau, comme en témoignent les 113000 occurrences dans le noyau Linux, par exemple).

Pour autant, le code incriminé est loin d’être simple. Pour entrer un peu dans le détail, la faille est présente dans la partie du code qui valide la signature des clés temporaires, négociées entre le client et le serveur pour sécuriser la connexion SSL ou TLS. Dans les faits, cette validation n’est pas effectuée ; il est donc possible d’utiliser n’importe quelle clé. Seuls les algorithmes DHE (Diffie Hellman key Exchange) et ECDHE (Ellipitic Curve Diffie Hellman key Exchange) utilisent cette partie du code, mais la faille peut être exploitée même lorsque le serveur propose d’autres algorithmes (puisque l’attaquant peut contrôler celui qui va être utilisé pour communiquer avec le client).

On est donc très vraisemblablement en face d’une erreur involontaire proche de la typo, et surtout bien moins simple à détecter qu’elle n’en a l’air :

  • Le code incriminé se trouve au cœur d’une bibliothèque implémentant des algorithmes complexes, que peu de gens maîtrisent. Comme l’a montré le bug introduit par un développeur Debian dans OpenSSL en 2008 (et comme le confirme le présent bug), changer une seule ligne peut remettre en question toute la sécurité de l’implémentation.
  • Ce type d’erreur n’est pas facilement identifiable par les compilateurs ou les analyseurs de code. GCC et CLang détectent ainsi, si on le leur demande, qu’une partie du code est effectivement « morte » (puisque tout ce qui suit le « goto fail » ne sera jamais atteint).
  • L’indentation du code rend le problème plus difficile à repérer lors d’une lecture rapide. Le cerveau humain est tellement efficace qu’il faut parfois faire un effort pour voir ce type d’erreur.

Figure 2

Figure 2 : Connaissez-vous cette chanson ? Avez-vous vu l'erreur dans les paroles ?

 Des bugs d’implémentation SSL sont malheureusement régulièrement identifiés (ni OpenSSL ni NSS n’y échappent), et on peut au moins se féliciter que la faille corrigée par Apple ne permette pas d’exécuter du code à distance sur votre iPhone.

Bref, sans chercher à minimiser l’impact de cette vulnérabilité, il est délicat de jeter la pierre au développeur fautif. En 29 mois, pas une seule personne ne l’a identifiée et signalée. La bibliothèque fautive fait en outre partie du code open source d’OSX Maveriks, disponible depuis plus de 5 mois.

Le retour du grand complot

Évidemment, dans les minutes qui ont suivi la publication de ce correctif et l’identification du bug, le programme PRISM a pointé le bout de son nez dans toutes les discussions. La société Apple a-t-elle délibérément introduit cette faille dans son code sur demande de la NSA ? La NSA a-t-elle plutôt employé ou soudoyé quelqu’un ? J’ai personnellement audité beaucoup de code et vu trop de bêtises pour mordre à l’hameçon aussi facilement.

Ceci étant, il est probable que cette faille ait été activement exploitée ; cela pourrait expliquer en partie la découverte récente de nombreux certificats SSL invalides rapportée par la société Netcraft.  Et puis, au risque d’apporter de l’eau au moulin de nos amis paranoïaques, constatons que la NSA a ajouté Apple à son programme de surveillance en octobre 2012, quelques jours seulement après la sortie du premier système vulnérable (iOS 6.0).

Les leçons à tirer

Si l’erreur est humaine, celle-ci aurait pu être évitée d’au moins deux façons :

  • En écrivant des tests spécifiques, permettant de s’assurer que tous les cas traités dans le code étaient correctement gérés. Je ne le répéterai jamais assez : en plus d’aider à la validation fonctionnelle, la rédaction de tests (unitaires, notamment) permet aussi d’améliorer la sécurité du code.
  • En effectuant un audit de code. Un audit de code approfondi et ciblé aide bien souvent à détecter des anomalies ou des erreurs qui sont complexes ou impossibles à identifier et à traiter avec une démarche d’intrusion ou par une analyse automatique.

Le mal étant fait, je vous invite à mettre à jour vos systèmes au plus vite. Et pour éviter de vous retrouver dans la même situation gênante qu’Apple, pensez à faire auditer vos applications et bibliothèques sensibles !

Emmanuel le Chevoir

Consultant Sécurité

Catégorie(s) :
Date : 25 Février 2014