Blog technologique de Soogest

Afin de rendre cet article intéressant et compréhensible même pour une personne n'ayant pas de connaissances avancées en cryptographie, nous commencerons par expliquer en quoi consiste l'architecture utilisée, puis le problème en lui-même. Si un point vous parait toujours obscur, n'hésitez pas à vous référer aux très bien renseignés portails de la sécurité informatique et de la cryptologie de Wikipedia, ou bien à nous poser des questions par les commentaires.

Mais qu’est-ce donc que le SSL ?

Le SSL (Secure Sockets Layer) est un protocole de sécurisation et de chiffrement des échanges entre deux machines. De façon synthétique, lors de l'établissement d’une connexion entre deux machines utilisant le protocole SSL, des clefs sont générées à partir de nombres aléatoire puis utilisées pour chiffrer les messages à envoyer et déchiffrer les messages reçus.



De cette façon, même si quelqu'un arrive à intercepter un message ne pourra pas le lire, puisqu'il ne possède pas la clef requise.

Le protocole SSL, et son successeur le TLS, sont largement utilisés sur le web. On notera quelques exemples importants :

• le https (achats en ligne, consultation de mails via internet, de comptes bancaires, ou pour rester dans l’actualité : télédéclaration des impôts)
• le VPN (réseau privé virtuel)
• le SSH (exécution de commandes à distance)
  
  

Qu’est-ce qu’OpenSSL ?

OpenSSL est une implémentation open source du protocole SSL, réalisée par une équipe indépendante. Les programmes développés par cette équipe peuvent donc ensuite être réutilisés selon les règles de la licence OpenSSL, similaire à la licence Apache.

Quelle était la faille ?

Commençons par un rapide résumé du fonctionnement de la génération de clefs par OpenSSL.

La première étape consiste à obtenir des nombres aléatoires. Pour ceci, on utilise un générateur d’entropie, processus qui collecte des données variées et par nature non prévisibles. Les données ainsi récoltées constitueront la graine du générateur de nombres aléatoires. Ledit générateur est un programme qui se sert de cette graine pour produire des nombres aléatoires de qualité cryptographique (i.e. indiscernables d’une série naturelle de nombres aléatoires). En effet, le principal problème des nombres générés de façon informatique est leur propension à suivre des schémas, les rendant vulnérables à des attaques bien plus rapides et/ou plus efficaces que la simple force brute. Cet éceuil est ainsi évité.



La faille constatée dans le paquet OpenSSL de Debian consiste en une mauvaise collecte des données par le générateur d’entropie. Le résultat en pratique est que les nombres aléatoires, puis les clefs en découlant, ne dépendent plus que du numéro de processus d’OpenSSL, au lieu de dépendre de nombreux paramètres collectés par le générateur d’entropie. Les clefs générées sont donc très peu variées. Et en cryptographie, qui dit “peu de combinaisons différentes” dit “attaque aisée par force brute”...



Avec une architecture de la machine, un type de clef et une taille de clef données, seules 32767 combinaisons sont possibles. Et l’identifiant du processus ayant beaucoup de chances d’être bas (OpenSSL étant généralement lancé au démarrage du système), les clefs sont en pratique encore bien moins nombreuses.

La génération de la totalité des clefs possibles a immédiatement été entreprise par Debian et Ubuntu afin d’établir une blacklist de clefs faibles... Ainsi que par les communautés de hackers. Les dictionnaires, d’une vingtaine de mégaoctets, sont désormais disponibles sur internet. On estime actuellement que le crack d’une clef SSL atteinte de cette faiblesse, à l’aide du dictionnaire adéquat, prendrait tout au plus quelques heures.

Comment cette faille est-elle apparue ?

La faille a été ouverte par un développeur chargé d’adapter du code d’applications externes pour les besoins spécifiques du système d’exploitation Debian ; un mainteneur. Ce mainteneur ayant, grâce à un outil de débugging, constaté ce qui semblaient être des anomalies dans le code source a tout simplement commenté (“désactivé”) les lignes incriminées.

Lesdites anomalies correspondaient en une lecture de données non initialisées en mémoire vive. Dans le cadre d’un programme classique, cette façon de faire est fortement déconseillée, les données ainsi lues pouvant correspondre à n’importe quoi. Or, dans le cas d’un générateur d’entropie... C’est exactement ce que l’on recherche.

Et maintenant ?

Cet échec met en relief des faiblesses majeures dans les systèmes open source utilisant le concept de développeurs / mainteneurs. En effet, le mainteneur travaillant sur du code qu’il ne comprend pas -ou moins bien que les développeurs- est plus propice à faire des erreurs, qui elles-mêmes peuvent avoir des conséquences majeures.

La solution généralement mise en place, appelée upstream, consiste à laisser la charge des modifications du code source aux mains des développeurs. Les mainteneurs ayant dans cette optique uniquement un rôle de vérification, de rapport de bug et de suggestion de nouvelles fonctionnalités. Cette politique est largement adoptée dans le monde open source hors-Debian, comme le montre par exemple cette page du projet Fedora. Une réelle volonté d’upstream de la part de Debian aurait sans nul doute prévenu cet incident.

Cependant, au de là de ces orientations structurelles, d’autres paramètres viennent compliquer le tableau.

En effet, le mainteneur responsable de cette modification n’était à la base intervenu dans le projet Debian qu’avec une volonté d’aide ponctuelle. Suite à de nombreux départs, il s’est retrouvé unique mainteneur du paquet OpenSSL. Voilà, s’il en fallait encore une, la preuve que le manque de développeurs est un danger pour la sécurité et la fiabilité d’un système open source.

Nous pourrons aussi remarquer que ledit mainteneur avait demandé de l’aide à propos de ce problème, et s’était vu répondre par un membre de l’équipe OpenSSL qu’il pouvait modifier les lignes problématiques à des fins de debug. Les membres de l’équipe OpenSSL se défendent désormais en avançant le fait qu’ils n’avaient aucune idée de l’identité de qui posait cette question, ni de l’utilité finale de ce code. Le problème apparait finalement plus lié à un manque de communication entre les différents développeurs.

Pour finir sur un point positif, on pourra noter que le bug a été reporté par un autre développeur travaillant sur ce code, ce qui aurait été impossible dans un code non open source. Le modèle est sauf... S'il apprend de ses erreurs.