Il y a eu pas mal d’infos sur le sujet, généralement assez technique et en anglais, aussi je vous fais un petit résumé de la crise.
Le 8 avril dernier, une faille dans le logiciel OpenSSL, surnommée Heartbleed, a été rendue publique. OpenSSL est le logiciel le plus utilisé au monde pour chiffrer les communications entre le navigateur et le site Web. Les banques, les e-commerce, les emails, les réseaux sociaux, tous utilisent SSL, pour éviter que l’on puisse intercepter vos communications. Et la plupart utilisent OpenSSL sur leurs serveurs pour permettre une connexion SSL.
Ce n’est pas le protocole SSL ou le chiffrement en général qui est mis en cause mais bien le logiciel OpenSSL.
Au début, on a cru à une faille critique qui permettait à l’attaquant de lire les communications. Toute personne exploitant cette faille aurait pu récupérer vos identifiants de banque au moment de votre login par exemple.
Il s’est avéré que c’était bien pire encore.
La faille permet de récupérer, à chaque heart beat (d’où le surnom) – c’est à dire à chaque fois qu’un client dit au serveur “je suis toujours connecté” – 64K de mémoire de l’ordinateur cible, au hasard. Parce que cette faille utilise le heart beat, elle n’implique pas d’authentification ou de log, elle est donc parfaitement silencieuse, ne laisse pas de trace, et n’importe qui sans autorisation peut se connecter et en tirer parti.
Tous les sites les plus importants sont concernés incluant tous les réseaux sociaux, fournisseurs d’email, banque, etc. En fait, même les services en ligne qui ne sont pas des sites, comme Steam, sont affectés.
On ne peut pas choisir les 64K sur la machine, mais si on répète l’opération suffisamment longtemps, on peut récupérer la plupart des choses en mémoire. Comme un serveur a généralement énormément de cache en mémoire, il y a de tout dedans : les mots de passe, adresses emails, clés privées, certificats d’authentification, présents dans le programme, etc. En prime, en récupérant la clé privée, on peut écouter les connections au site ou carrément se faire passer pour le site, puis facilement récupérer numéros de carte de crédit, emails, messages privés, et tout ce qui transite.
C’est une catastrophe.
A qui profite le crime ?
La question n’est pas qui peut en tirer parti. La réponse à cela est tous les attaquants : pirates, gouvernements, armées, services secrets et même script kiddies.
Non. Le débat est plutôt de savoir si la faille était intentionnelle ou pas.
D’un côté, j’aime beaucoup cette phrase attribuée à Napoléon :
N’attribuez jamais à la malveillance ce qui s’explique très bien par l’incompétence.
Et l’incompétence, il en a fallu, car il ne s’agit pas d’une faille de cryptographie complexe, mais d’une erreur de débutant en programmation C. Dans un logiciel qui a la portée de OpenSSL, ça amène sérieusement à se poser des questions, malgré le déni de l’auteur.
Par dessus se rajoute une déclaration d’Assange, qui enfonce un clou dans le cercueil, en expliquant que de nombreux logiciels Open Source sont complètement vérolés par la NSA, incluant des distributions Linux aussi réputées que Debian.
Comme souvent sur Internet, ce sont les commentaires de l’article qui sont les plus intéressants. On y note notamment plusieurs personnes, se présentant comme des professionnels de la cryptographies, débattant avec des argumentaires très bien construits de l’implication probable de la NSA et d’autres services secret dans la mise en œuvre de cette faille, et de son exploitation.
D’un côté, Bloomberg a annoncé que la NSA, a défaut d’avoir créé le bug, savait à son propos depuis le début et l’a exploité. De l’autre, la NSA nie (putain la NSA a un compte Twitter ?).
En tout cas, avec la révélation de Prism, il ne tient plus de la théorie du complot mais de faits que ces entités cherchent par tous les moyens à obtenir la main mise sur les réseaux d’information. L’idée qu’ils aient créé cette back door parait donc plausible, bien qu’improuvable.
Et surtout, si c’est le cas, combien d’autres accès aussi radicaux ont-ils à leur disposition ? Mon frère me disait dernièrement :
Je ne sais pas pourquoi ça te surprend encore. Tout en informatique a été craqué. Tout. Depuis toujours. On crack les playstations, Windows… Pourquoi tu crois que tes systèmes de sécurités ne sont pas craqués aux aussi ?
Sous prétexte que tout le monde les utilise, qu’ils sont Open source et que des gens vachement plus intelligents que nous les ont vérifié, on fait confiance à ces systèmes. Mais si la porte blindée est attachée à un mur en BA13 et qu’on ne le sait pas ?
Que faire pour l’utilisateur ?
Comme l’a recommandé Mathieu Agopian, d’abord changer tous ses mots de passe, pour tous ses sites. C’est là qu’on apprécie lastpass.
Je sais pertinemment que personne ne va le faire. Les gens ont une forte tendance à se plaindre que tout le monde est pourri et qu’on ne peut rien y changer, mais dès qu’il faut mettre la main à la pâte, y a plus personne. C’est pareil pour le recyclage, le boycott ou la lecture des programmes électoraux.
Et puis ils n’ont rien à cacher, pas vrai ?
De plus, si il existe d’autres failles de ce genre, ça ne résoudra pas le problème général, qui est politique et social. L’informatique n’est qu’un outil, on ne résout pas avec de la technique les problèmes d’un peuple. Même si ça aide.
De plus, le problème n’est pas complètement résolu côté fournisseur. Il faut que tout le monde mette à jour ses certificats, et les autorités de certifications croulent sous les demandes. Elles n’ont pas une infra prévue pour ça. Ensuite, certains outils ne pourront pas se changer. OpenSSL est présent dans de nombreux systèmes embarqués. Si vous mettre en sécurité implique jeter votre appareil et en racheter un neuf, vous pouvez être certain que que ça se fera encore moins que changer les mots de passe. Et je ne vous parle même pas de l’industrie. Je met ma bite à couper que dans le domaine des transports il y a des tas d’équipements bien trop chers à changer pour qu’ils soient sécurisés. Les professionnels vont donc jouer la carte de l’obscurité et serrer les fesses.
La désillusion sur l’Open Source
Ce qui fait mal au fion, c’est l’évidence de la réponse de Wolf dans un des commentaires de l’article sur Asssange, quand quelqu’un demande des solutions :
I think the reason you’re not receiving much of an answer on this is the reason I gave above – there are none. We’re in a place of no good options.
Car quand il s’agit du système général qui joue contre celui qu’il est censé servir, changer de logiciel ne sert à rien. On pensait que parce que les systèmes ouverts étaient transparents, ils n’étaient pas attaquables de cette manière. Des milliers d’yeux pour regarder le code source, qu’ils disaient.
Heartbleed nous montre une histoire bien différente.
OpenSSL s’est révélé être extrêmement difficile à auditer, car il est très complexe, sa documentation est réputée lacunaire sans compter qu’il faut de sacrées compétences pour ne serait-ce que commencer à proposer de participer.
En clair, la taille, la complexité et l’accessibilité des projets libres les plus importants font un sérieux contre poids à la fameuse garantie de la revue de pairs. C’est pour cette raison que des projets comme Android ne sont pas considérés comme libres par beaucoup : seul Google a les ressources pour étudier tout le code source. On manque de gens compétents, ainsi que de temps et d’argent. Il y a de plus en plus d’informaticiens, mais de moins en moins, proportionnellement, sont qualifiés. Beaucoup de techniciens, peu d’ingénieurs ou de hackers, malgré le titre sur le CV. Et encore moins qui sont motivés pour mettre les mains dans le cambouis du FOSS.
Cela veut-il dire qu’il faut jeter le bébé avec l’eau du bain ?
En fait, si cette faille avait été dans un logiciel propriétaire, nous n’aurions jamais été au courant. Elle a été découverte par hasard lors d’un audit d’un système qui n’a absolument rien à voir, par une équipe de sécurité Finlandaise. Les ingénieurs ont matraqué leur cible de tests aléatoires et sont tombés sur un problème. En cherchant l’origine du problème, ils se sont aperçus que le souci ne venait pas du produit testé, mais d’OpenSSL. Parce qu’ils avaient le code source, ils ont pu pointer du doigt la faille et prévenir les auteurs d’OpenSSL.
Entre temps, l’équipe de sécurité de Google (là encore, ça fait jaser car ils ont la réputation d’être proches de la NSA) a publié le bug et le correctif, et la couverture de presse vend le tout comme étant leur propre découverte.
L’Emo de la fin
Donc non, les logiciels Open Source ne sont pas vaccinés contre les failles majeures sous prétexte que le code est public.
Oui, il y a un soupçon grave de sabotage, à l’heure actuelle (et probablement pour longtemps) il n’y a aucune preuve. On peut s’attendre à une grosse vague de rejet de cette idée pour cause de “théorie du complot”. Ça ne change pas beaucoup des débats habituels dès qu’on parle de sécurité. C’est fou comme les gens sont prêt à jouer la carte de la présomption d’innocence pour défendre des grosses institutions boîtes noires au passé trouble et désignent coupable les accusés de pédophilie dès qu’ils voient leur tête au 20H…
La différence, c’est l’enjeu, et il est de taille. On parle pas d’une déchirure du slip, on parle d’être complètement à poil avec un bout du string cassé qui sort de l’anus.
Enfin oui, l’Open Source, offre toujours de meilleures garanties de sécurité en la matière que le logiciel fermé. Plus de transparence, plus de vitesse de réaction, disponibilité immédiate et pour toujours des correctifs, etc. Mais surtout, on vient d’en parler, si il s’agit de sabotage, le problème est politique et social, pas juste technique. Face à cela, un système démocratique, comme l’Open Source, a plus de chance de jouer en notre faveur qu’un système oligarchique de logiciel propriétaire. Reste à vérifier si l’élitisme du savoir ne risque pas de créer une oligarchie d’un autre genre côté FOSS. Sans compter les innombrables problèmes d’ego.
Mais ça ne suffit pas. Et à la lueur de ce genre d’affaire, il va falloir que la communauté du libre, principale gardienne des plus gros codes sources ouverts, se réorganise pour à la fois faire le ménage dans la base de code existante et filtrer à l’entrée les potentiels saboteurs. Qu’ils soient incompétents ou malveillants.
J’aimerais pas être dans les chaussettes de Linus en ce moment.
Malheureusement wikipedia est la preuve que des règles plus restrictives pour participer n’empêche pas les lobbyistes de pourrir le contenu mais apporte bel et bien un énorme frein à l’entrée de sang neuf. Ce qui n’arrange pas nos affaires, dans un monde où la complexité des sujets augmente plus vite que la compétence des gens qui pourraient participer. La revue communautaire reste le moins pire des systèmes, comme la démocratie pour Churchill, mais ça me colle un petit coup de blues tout ça quand même.
j’attends mon nouveau mot de passe du blog alors :) sinon pourrai plus faire Me Cappello :D
On utilise pas HTTPS sur sam et max, donc pas de heartbleed.
Bonjour,
bon article
2 coquilles : contre les failles majeures sous prétexte que le code est public
Je ne pense pas qu’on puisse considérer l’auteur de la faille comme incompétent, il code en C sur le projet OpenSSL c’est pas rien, il a fait une boulette, ça arrive, et il doit se sentir bien mal maintenant.
Par contre on peut dire qu’il a été négligent en effet la non vérification préalable du contenu des variables passées en paramètre de memcpy() relève plus d’une négligence que de l’incompétence.
Je ne suis pas dans le saint des saints mais d’hab ; ya pas un reviewer avant que le code soit approuvé ? Si oui, combien sont passés à travers son code soit disant QQ pour un dev en C ? Soit ya un pb de compétence des reviewer soit un probleme de process pour la validation d’un bout de code pour une soft aussi “sensible”, non ?
quand tu parles de mur en BR13, tu voulais sans doute parler des plaques de plâtre “BA13″.
@foxmask : De ce que j’ai pu lire, il n’y a eu qu’un seul reviewer, qui était déjà bien débordé. Ce qui expliquerait que ce soit passé à la trappe…
N’y connaissant rien ou presque en C je ne saurais dire si le mec est incompétent ou pas, mais visiblement il se rend compte de son erreur (et le reviewer aussi). Perso je suis pas du genre à juger coupable sans preuve, donc à priori il serait plus incompétent/pressé/débordé que malveillant — selon mon humble avis.
Pour le coup toute cette histoire de Heartbleed me conforte dans l’idée de se passer des mots de passe dans la conception de sites ou applications (cf. https://medium.com/cyber-security/9ed56d483eb + https://medium.com/cyber-security/680d97eddb01).
Ah ouais, quand même…
Par contre, petite correction : tu parles de récupérer de la ram au hasard sur l’ordi, ce ne serait pas plutôt un bout de la ram allouée au programme ? Que ça récupère le cache du serveur web, d’accord, mais récupérer une partie de la ram hors processus, je ne vois pas comment.
Merci à tous pour vos corrections et remarques.
@Yamakaky : effectivement la phrase fait l’amalgame entre ce qu’on peut récupérer en mémoire, et ce qu’on peut récupérer en écoutant la connexion après avoir obtenue les clés privées en mémoire. Je corrige.
@bob : je vois ce que tu veux dire, mais le fait qu’il n’y ai pas d’audit automatisé avec des outil de détection de ce genre de failles et d’attaques floues lancées à chaque build, c’est de l’incompétence sur un logiciel comme OpenSSL. Que l’incompétence soit liée à un manque de ressource est tout à fait possible. J’aimerais pas être à la place du mec en ce moment, il doit être complètement dégouté.
en meme temps, quand tu regardes que OpenSLL recoit 2000$ de dons par ans… (http://sebsauvage.net/links/?CjQyCg)
perso, on m’empechera pas de penser qu’avec ne serait que dix fois plus, ils pourraient au moins embaucher un reviewer a temps plein pour ce genre de boulot… un peu comme Linus et Linux. et comme le dit Seb, ca ne couterait pas tres cher au gros du secteur qui font un usage monstrueux de cette librairie
Salut Sam,
et donc lastpass serait passé à travers Heartbleed ? X)
Je lis ton blog depuis un bout de temps (parce que j’adore) mais je n’étais jamais intervenu. Là je n’ai pas pu résister, désolé. :)
Autre petite coquille : on met la main à la pâte mais rarement à la patte (sauf avec son chien).
@Teocali: absolument.
@fmommeja : comme les données envoyées à lastpass sont chiffrées côté client avec forward secrecy, ils n’ont rien pu récupérer sur leur service. De plus, si on utilise lastpass, on a un mot de passe différent pour chaque site, si un site est compromis, les gars n’ont pas le mot de passe de tous tes autres sites. Enfin, avec lastpass, changer les mots de passe pour chaque site est beaucoup plus rapide car on les génère facilement).
Si on rajoute le fait qu’ils ont été très pro et ont tout de suite communiquer sur les implications sur leur service, je dirais que franchement, c’est une super boîte. Bravo lastpass.
Bon, j’ai bien un chien sous la main mais tu as raison, on va corriger ça.
En fait la seule attaquer qu’on ait pu faire sur lastpass qui aurait marché, c’est du phishing (mais on a on a pas reçu de mail de ce genre durant les 2 ans) ou du MIM directement au coeur de l’infra réseau. Sur ce dernier point par contre, personne n’est protégé, si un gouvernement l’a fait, on est tous niqué, pour tous les sites. Et la NSA s’est certainement fait plaiz.
@sam
oui voilà c’est plus ça, de bonnes pratiques à mettre en place sur la gestion du projet. Mais bon les exemples abondent, les copiés/collés foireux pour Ariane 5 (un crash ) ou le Therac-25 (plusieurs morts), le code spaghettis tueur chez Toyota …etc … faut toujours attendre la catastrophe, ou une grosse amende (cf Toyota), pour commencer à s’y mettre.
Oui, c’est plutôt à ça que je pensais…
Ce qui me dégoûte surtout, c’est ça : http://sebsauvage.net/links/?CjQyCg
À mon avis, c’est pas spécialement des gens très qualifiés qu’il nous manque, mais, globalement parlant, de la bonne volonté.
L’incompétence n’est pas qu’un question de qualification. C’est aussi une question légale, morale et de ressource. Cela signifie juste qu’on que l’on est pas capable.
Un tribunal peut se déclarer incompétent car il n’a pas juridiction, ça ne veut pas dire que le mec ne sait pas ce qu’il fait.
Les auteurs peuvent être incapables de gérer le projet par manque de ressource financières et temporelles. Et donc être incompétent.
Déclarer l’incompétence n’est pas une trouver un coupable, c’est une énonciation de statu. La culpabilité est largement répartie sur de nombreux acteurs, techniquement, et moralement.
En l’occurence je pense que le mec sait très bien ce qu’il fait. Moi aussi j’introduirs des bugs de merde dans des codes Python très simple sous le coup de la fatigue ou du stress.
La NSA peut parfaitement mettre en place des mesures pour garder l’équipe dans un état d’incompétence et les laisser introduire des bugs dans un code qu’elle audite en permanence dans le but de les utiliser.
Il n’y a pas qu’une seule possibilité, c’est bien le problème. Sinon ça serait facile à régler.
Merci pour l’article.
J’aimerais bien avoir des exemples d’utilisation d’OpenSSL sur les systèmes embarqués impossibles à mettre à jour : pourquoi chiffrer ses données ? pourquoi utiliser TLS ? pourquoi utiliser OpenSSL qui est assez lourd ?
Oui c’est quelque chose à essayer de mitiger, et TLS le fait très mal. Ça a été dit et redit, on n’a malheureusement toujours pas d’alternative simple aujourd’hui (ce serait pourtant possible).
Non, Android n’est pas considéré comme libre par beaucoup parce que Google empêche activement les gens de participer. LibreOffice est intéressant de ce point de vue : on pensait que cette masse informe de C++ était ingérable, et finalement depuis que la communauté s’en occupe la qualité du code augmente sans cesse et de nouveaux développeurs sont attirés. Il y aura toujours des bugs, mais ce n’est pas très grave dans ce cas.
Il faut saluer les efforts faits par les gros projets pour attirer des contributeurs : Mozilla et ses mentored bugs, Python et son devguide, les bugs Gnome Love, le challenge Eudyptula pour Linux etc. etc.
Le succès de GitHub à lui tout seul montre bien que ce n’est pas le cas : de plus en plus de gens contribuent au libre. Mais il y a aussi de plus en plus de projets, et certains se débrouille
@Sam Mon post se rapporte surtout au passage de ton article où tu dis qu’il y a beaucoup de techniciens et peu d’ingénieurs et de hackers. Je ne jugeais pas le moins du monde de la compétence des programmeurs d’OpenSSL, je ne le me permets pas vu la mienne en la matière.
Et, bien sûr, la qualification et la compétence sont des notions différentes. Je suis bien d’accord avec toi. :)
Maintenant je me sent complètement à poil avec un bout du string cassé qui sort de l’anus :-D et en prime j’ai perdu un peu le moral :-/
Merci pour ce très bon article.
J’espère qu’il y a pas de faille comme ça dans le firewall d’Open Office, sinon je vous raconte pas la merde.
Bon article (comme d’hab), pour ma part je penche plus sur un trop plein de confiance de la part du reviewer. C’est machin qui as fait le patch, il a pas l’habitude de faire de la merde, je relie pas, je valide de suite. Je pense pas à de la malveillance volontaire.
Merci pour ce très bon article qui remet un peu d’ordre dans tout ce qu’on a pu lire. (Et il y a eu du lourd comme bêtises, voir : http://linuxfr.org/users/perdu/journaux/heartbleed-petit-best-of-des-journalistes )
Et comme c’est la première fois que je commente un de vos article, j’en profite pour dire un merci global ! Vous faites un super taf ! ;-)
et encore en france on en fait pas grand cas… je regarde tous les matins le journal de radiocanada, et là bas l’état canadien a pris l’histoire très au sérieux : les prelevements d’impots sont suspendus, etc ….
je pense que l’on va en reparler d’ici 2 ans, quand un ou deux grands pontes seront touchés en france…
Pour LastPass, autant je trouve(ais) cette extension très utile, et surtout la seule à avoir de l’authenfication forte (Yubikey) et de la synchro entre les postes (ce que n’a pas Keepass et tout le reste), autant suite à HeartBleed, j’ai un *GROS* doute sur eux :
https://twitter.com/LastPassHelp/status/454730429443346432
Sans parler que du coup ce n’est pas du logiciel libre, donc qu’on ne sait au final pas vraiment ce qui est réellement fait de nos données…
je n’ai pas compris le débat du tweet, tu peux éclaircir ?
Ils ont fait un outil qui permet de tester nos sites enregistrés afin de voir s’ils étaient sensibles à Heartbleed ou pas.
Et ils ont été capables de me lister l’intégralité de mes 400 sites en moins de 2s, dont certains sites qu’ils n’ont pas pu calculer juste sur le pouce (site avec une proba ultra faible que quelqu’un soit déjà passé avant, genre des forges privées).
Ça sent donc du précalcul à partir de tes données…
Et en wiresharkant ma ligne, y’a pas eu d’accès TLS, donc tout était de toute façon fait côté serveur. Donc encore une fois avec mes données… en clair…
Cette histoire aura eu le mérite de remettre en cause la fameuse qualité allemande ;).
Encore un coup de Montebourg !
Dans la phrase de ton frère :
merci de cet article, le plus complet en français à mon avis, avec http://www.heartbleed.fr
Si j’ai bien suivi ton explication, le serveur renvoie fréquemment 64Ko de données pour tester la connexion. Mais est-il nécessaire que ces données soient présentes sur le serveur? N’est-il pas possible de renvoyer la même quantité de données générée aléatoirement?
@clem: yep merci.
@Rif, j’ai pas compris la question.
Rif, le client dit : “si tu es encore là, renvoie moi PATATE, qui fait 6 caractères”. Le serveur répond “PATATE”. Tout va bien, il est là. (C’est le client qui choisit la chaîne “PATATE”, pour être sûr que le serveur l’a bien entendu.)
Le souci c’est que le serveur faisait confiance au client qui lui donnait la longueur de “PATATE”. Suppose maintenant que le client dit au serveur “si tu es encore là, renvoie moi PATATE qui fait 65536 lettres”. Comme en C 1/ les chaînes sont stockées sous formes de tableaux de caractères 2/ les variables sont placées à côté les unes des autres en mémoire, le serveur ne va pas répondre que “PATATE” mais aussi les 65530 caractères qui se trouvaient à côté du tableau à ce moment là. Exemple illustré : http://xkcd.com/1354/
Les gens ont comme ça trouvé des login/mot de passes de gens qui dialoguaient avec le serveur à ce moment là. Mais on ne peut pas accéder à “64K de la mémoire cible, au hasard” comme le dit l’article : on peut accéder aux 64k à côté du tableau qui sont, pour le serveur nginx, très loin de la clef privée elle-même. Dommage, cette protection n’est pas suffisante : on peut reconstruire la clef privée à partir de données proches du tableau “PATATE” (des facteurs de la clef privée, semble-t-il).
solved ?
http://www.libressl.org/