Comment je suis tombé sur la vulnérabilité des clés faibles de Debian

Comment j’ai fini par tomber sur la vulnérabilité des clés faibles de Debian

• En mars 2008, l’auteur travaillait chez Engine Yard (EY)
• À l’époque, EY aidait GitHub en lui fournissant gratuitement de l’infrastructure
• Avec la croissance de GitHub, un problème est apparu : les connexions SSH devenaient lentes
• GitHub gérait alors les clés SSH avec la méthode standard, via le fichier ~/.ssh/authorized_keys
• Lorsqu’un utilisateur se connecte, SSH ouvre ce fichier et recherche linéairement une clé correspondant à celle présentée par l’utilisateur
• En général, cela ne pose pas de problème car il n’y a que quelques clés, mais avec beaucoup d’utilisateurs comme sur GitHub, cela devient lent

Décision d’utiliser une base MySQL à la place du fichier authorized_keys

• Après avoir examiné plusieurs solutions, il a été décidé de modifier OpenSSH afin que la recherche de clés se fasse dans une base MySQL
• Cette décision a été prise avec prudence, et beaucoup d’efforts ont été fournis pour ne pas nuire à la sécurité
• Le changement a été déployé début avril 2008, ce qui a résolu le problème de lenteur des connexions SSH

Quelque chose d’étrange se produit

• Un mois plus tard, début mai, un problème survient : certains utilisateurs peuvent accéder en SSH aux dépôts d’autres utilisateurs
• L’enquête révèle que des utilisateurs différents utilisent des clés ayant la même empreinte
• Cela ne devrait pas pouvoir arriver, sauf si les clés sont partagées
• Les utilisateurs disent ne pas se connaître et ne savent pas comment leurs clés auraient pu fuiter
• Le même problème est découvert chez d’autres paires d’utilisateurs
• Le seul point commun est qu’ils utilisent tous des systèmes Debian ou Ubuntu

Identification de la cause

• Le 13 mai 2008, la publication de DSA-1571-1 rend tout clair
• En nettoyant le code de génération aléatoire d’OpenSSL, un mainteneur Debian a réduit par erreur le nombre de clés possibles à environ 32 000
• Comme beaucoup de personnes s’inscrivaient sur GitHub et généraient de nouvelles clés en suivant les bonnes pratiques, des collisions se sont produites
• Par la suite, l’auteur s’est encore davantage impliqué dans ce problème, notamment en utilisant les clés faibles connues pour identifier des autorités de certification affectées

L’avis de GN⁺

• Pour découvrir une vulnérabilité aussi importante, il faut pouvoir se dire « c’est étrange » puis avoir le temps et l’énergie d’enquêter avec ténacité. En général, on n’a pas cette marge, donc il faut aussi de la chance.
• La plupart des gens sont pris par leur quotidien et ont du mal à remonter jusqu’à la cause profonde d’un problème. Redonner cette marge à notre secteur est un enjeu important.
• OpenSSL est l’une des bibliothèques de chiffrement les plus utilisées au monde, donc l’impact d’une telle vulnérabilité est immense. Cela montre bien à la fois les forces et les faiblesses de l’open source.
• Pour prévenir ce type de vulnérabilité, il faut renforcer la revue de code et les audits de sécurité, et examiner avec encore plus de prudence les modifications touchant aux parties critiques. Mais il n’existe pas de méthode parfaite.
• Malgré tout, l’open source garde un avantage : des experts peuvent examiner directement le code et y trouver des problèmes. Avec des logiciels fermés, ce n’est même pas possible.

[GN⁺]

Avis Hacker News

• Luciano Bello a découvert par hasard la vulnérabilité CVE-2008-0166, et d’après les logs IRC de l’époque, il fallait beaucoup de nombres premiers de petite taille et on n’obtenait pas à chaque fois le même nombre
• On a l’impression que tout le secteur a eu beaucoup de chance, parce qu’il y avait quelqu’un qui avait les compétences, le temps et l’énergie nécessaires au bon moment pour faire une énorme différence. C’est un cas qui illustre concrètement les maximes « beaucoup d’yeux » et « la lumière du soleil est le meilleur désinfectant ». Même si la probabilité que quelqu’un tombe sur un bug par hasard est très faible, il finit par être découvert parce qu’il y a des gens pour le faire. À l’inverse, avec du code propriétaire/fermé, cette probabilité est nulle
• Le changement à l’origine de cette vulnérabilité n’a pas été fait dans la précipitation. Le mainteneur a soulevé le problème sur la mailing list OpenSSL, demandé des retours et proposé une solution, et a reçu quelques commentaires, y compris de l’upstream. Le résultat a été une vulnérabilité terrible, mais cela ressemble à un cas extrêmement malheureux où personne n’a vu le problème
• GitHub a conclu que la meilleure option était de patcher OpenSSH pour récupérer les clés indexées par empreinte dans une base de données MySQL. Il semble qu’ils aient choisi MySQL plutôt que SQLite parce qu’ils cherchaient à accélérer l’accès à ~/.ssh/authorized_keys, un type de situation où MySQL pouvait justement exceller
• Cela fait réfléchir à la possibilité qu’une chose similaire arrive dans la fonction de génération de seed d’un portefeuille matériel Bitcoin populaire, ainsi qu’à ses conséquences
• La détection des clés RSA partageant un facteur commun p ou q à l’aide du PGCD était aussi un épisode intéressant
• On voit que des temps de connexion SSH lents constituent un indice qui peut valoir la peine d’être creusé, pour diverses raisons
• Le RNG d’OpenSSL était initialisé avec de la mémoire de pile non initialisée et le PID, et même sans le patch Debian, le fait de se baser uniquement sur le PID pour l’initialisation semble déjà avoir été assez risqué
• Je me demande si GitHub exécute toujours cet OpenSSH patché
• La phrase disant qu’Ezra Zygmuntowicz a présenté GitHub à l’auteur et lui a donné du temps pour creuser le problème avec l’équipe GitHub est amusante, peut-être parce qu’on peut la lire comme si l’équipe GitHub elle-même avait un gros problème
• Je me demande combien de temps cela serait encore passé inaperçu si Luciano ne l’avait pas découvert. J’imagine que seuls quelques acteurs comme GitHub ou de grands fournisseurs cloud, qui stockent des milliers de clés de leurs utilisateurs, auraient pu tomber dessus par hasard