Heartbleed - Au coeur du problème |
Les plus technophiles d'entre vous auront entendu parler, ces jours derniers, de Heartbleed, la faille de sécurité affectant les accès cryptés à certains sites Web. L'impact et l'exemplarité de cet épisode méritent qu'on y revienne dessus. Tout d'abord, de quoi s'agit-il exactement ? Heartbleed, coté fonctionnement Pour résumer (et simplifier un peu), le problème touche OpenSSL, qui gère les échanges sécurisés entre par exemple un serveur Web (gmail, facebook, yahoo, etc) et le client (vous, votre voisin, un hacker, un pirate ou un agent de la NSA) qui y accède. Lors de ces échanges, le client peut demander des données au serveur, et, en exploitant une erreur de programmation, s'arranger pour recevoir, en plus de ces données, le contenu d'une zone mémoire utilisée préalablement par le serveur lors des échanges avec quelqu'un d'autre et malencontreusement non effacée. Ainsi, n'importe qui peut s'arranger pour obtenir des données qui ne lui étaient pas destinées. Ces données peuvent être totalement inutiles, mais aussi des données sensibles (noms d'utilisateur, mot de passe, échanges privés...). En récupérant beaucoup, beaucoup de données par ce biais et en les triant, une personne mal intentionnée peut récupérer des noms d'utilisateurs et des mots de passe, et donc pirater des comptes ou accéder à des données privées. Imaginez ce que ça peut donner s'il s'agit du serveur de votre banque en ligne... Heartbleed, coté programmation On peut légitimement se poser la question : pourquoi les données sensibles se sont-elles retrouvées en clair dans une zone mémoire non utilisée ? N'aurait-il pas été plus sûr, si cette zone mémoire n'était pas censée être utilisée telle quelle, de l'effacer ? OpenSSL est, sauf erreur, écrit en C. Un langage rapide, mais pas réputé pour la sécurité intrinsèque du code. En gros, on peut faire beaucoup de choses, qui vont très vite, mais ça crashe facilement, ça peut déborder, ça peut lire et écrire en dehors des endroits prévus, etc. On peut alors choisir de privilégier la sécurité ou la performance. La sécurité, c'est, lorsqu'une zone mémoire va être utilisée ou est libérée, de l'effacer complètement. La sécurité, c'est aussi d'utiliser un gestionnaire de mémoire qui va générer une "exception" (un arrêt du programme ou l'inscription dans un journal d'alerte) lorsqu'on accède un peu en dehors des zones prévues. La performance, c'est tout le contraire. Dans OpenSSL, on a visiblement choisi la performance. Heartbleed, coté autorités On ne sait pas vraiment depuis combien de temps la faille heartbleed est connue de certains. Il se murmure que la NSA l'exploite depuis plusieurs mois, voire plusieurs années, avec l'accord explicite des plus hautes autorités américaines. Et il est strictement impossible de savoir quelles données ont été lues par ce biais, d'en remonter la trace et ainsi de savoir qui a volé quoi. Le saint-Grââl de l'espionnage informatique. Heartbleed, coté philosophique Cela nous amène à nous interroger. Comment une faille de cette importance, et présentant ces conséquences, a-t-elle pu perdurer dans l'un des programmes Open Source les plus utilisés au monde ? On nous a présenté l'Open Source comme un schéma dans lequel la sécurité était maximale, car tous les programmeurs avaient la possibilité d'examiner le code, trouver les erreurs, les signaler et les corriger. Ainsi, aucun défaut majeur ne pouvait perdurer bien longtemps avant d'être repéré et traité. On s'aperçoit aujourd'hui que ce n'est pas vrai, en tout cas pas obligatoirement vrai. Heartbleed, coté "Open" Le beau scénario de l'Open Source ne peut fonctionner que si trois points sont respectés : 1- Il y a suffisamment de programmeurs compétents pour vérifier le code. 2- Le code est suffisamment clair pour permettre à tous de s'y retrouver facilement 3- Il y a plus de programmeurs "honnètes" pour chercher les failles que de pirates ou d'agents du gouvernement. Pour 1-, le nombre de programmeurs chevronnés est probablement grandement surestimé. Et dans ceux-ci, beaucoup ont autre chose à faire que d'examiner du code qui fonctionne (ou qui semble fonctionner) correctement. Pour 2-, sans avoir étudié le code source d'OpenSSL, beaucoup de projets Open Source semblent avoir été écrit avec les pieds par Hannibal Lecter. La syntaxe semble avoir été compliquée à dessein, les noms de fonctions et de variables semblent issus d'un manuel de codage russe, et les commentaires se résument souvent à une belle en-tête de fichier en ASCII Art. Pour 3-, Heartbleed semble avoir prouvé que les pirates et les cyberespions possèdent maintenant un avantage en terme de moyens et de main-d'oeuvre par rapport à la poignée de bénévoles décidés à passer leur week-ends à relire l'intégrale du code d'OpenSSL, on se demande pourquoi. Et maintenant, tout le monde est en train de se poser la même question : "celle-ci a été repérée, mais y en a-t-il encore beaucoup, des failles comme ça ?"... |
|
|
by Olivier Guillion | | | |
| Comments
Et pour savoir si un site est compromis |
Si, si, il y en a encore, pour lesquels la faille n'est toujours pas colmatée (j'en ai trouvé quelques-uns). Vous pouvez vérifier si un site est compromis grâce à ce lien : https://filippo.io/Heartbleed/ |
|
|
Sites impactés - changer son mot de passe |
|
|
|
|
|