Or, plus on creuse sur la question, plus on se rend compte que l’ami Schneier a effectivement raison. Heartbleed passera assurément à l’histoire comme étant une des plus grosses failles que l’Internet aient connu.

Pourquoi ça devrait m’intéresser et pourquoi est-ce si grave?

Mettons tout de suite les choses au clair : Heartbleed est ni un virus, ni un maliciel quelconque. C’est tout simplement une erreur de codage bête, mais importante. La faille Heartbleed est notable, car elle touche à OpenSSL, un protocole de sécurité qui permet à un ordinateur et à un serveur de valider qui ils sont. L’avantage de ce protocole est qu’il est généralement jugé comme étant efficace pour assurer une communication sécuritaire entre deux ordinateurs. De plus, il s’agit d’un projet en source ouverte. Cela veut donc dire qu’il est gratuit et que le code source est ouvert et disponible à ceux qui voudraient le regarder.

C’est grave, car OpenSSL est exploité par une flopée de sites web. Schneier affirme que c’est plus de 500 000 sites web qui exploitent ce protocole, mais cela me semble plus conservateur comme estimation. Cela est d’autant plus grave que la faille est, selon toute vraisemblance, active depuis plusieurs mois déjà, soit environ deux ans. Cela a des répercussions très concrètes pour l’ours moyen. On apprenait par exemple ce matin que le gouvernement fédéral s’était fait voler plus de 900 numéros d’assurance sociale en lien avec cette faille.

Pourquoi le terme «Heartbleed»?

Pour l’utilisateur qui s’intéresse plus ou moins aux questions technologiques, et aux questions de sécurité en particulier, il faut comprendre que ce nom fait référence à un processus se trouvant au centre même du protocole SSL. Quand deux serveurs sont sur le point d’entreprendre un échange sécurisé (certains diraient une poignée de main cryptée, ou encrypted handshake), ils mettent en place un processus appelé un battement de cœur (heartbeat).

Ce processus a essentiellement pour objectif de s’assurer que les deux ordinateurs qui communiquent ensemble soient encore en contact. Ainsi, si une des deux machines se voit déconnectée l’autre ne continuera pas inutilement à tenter de communiquer. Cette synchronisation, ce battement de cœur,  correspond plus ou moins à un ping-pong de données qui se doit d’être maintenue pour qu’il y ait poursuite du dialogue.

Allons-y avec un exemple plus concret. Le client (vous) refile son battement de cœur au serveur (le site de Facebook, admettons), ce serveur refile son battement de cœur en retour, et ainsi de suite. Durant toute la durée de cette «transaction», les deux ordinateurs se transmettent leurs battements cardiaques. Si à un moment donné le battement cardiaque se désynchronise pour une raison ou pour une autre, l’autre ordinateur impliqué dans le dialogue saura qu’il y a un problème. Donc, dans l’exemple mentionné plus haut, si des extraterrestres viennent voler les serveurs de Facebook, l’ordinateur client saura que le processus doit s’arrêter, car les battements cardiaques ne seront plus synchronisés.

Pour les gens de ma génération, cela correspond plus ou moins aux deux pignons sur lesquels une cassette audio était installée. Si un deux deux pignons cessaient de tourner, c’était généralement mauvais pour la cassette.

Oui, mais quossé ça fait Heartbleed?

Donc, comme le mot le laisse entendre, Heartbleed est relation directe avec ce battement de cœur. Pour les gens très techniques, je vous recommande tout simplement la lecture du site web expliquant en long et en large le bogue en question. Pour les autres, je vais essayer de simplifier. En fait, tout le problème réside dans cette toute petite ligne de code :

memcpy(bp, pl, payload);

Ce qui se passe ici, c’est que la commande memcpy est une commande qui copie des données et elle demande trois éléments d’information pour faire le boulot, soit les trois éléments dans la parenthèse. Le premier est la destination finale de la copie, le second est où se trouve l’information qui doit être copiée et le troisième correspond à la quantité de données que l’ordinateur va trouver lorsqu’il fera la copie.

Dans le cas, de l’OpenSSL bp est l’endroit sur le serveur, pl est l’information envoyée par le client avec son battement de cœur, et payload est un nombre qui dit tout simplement la taille de pl.

Le principe que l’on doit comprendre ici, c’est que l’on peut exploiter le fait que les données dans la mémoire ne sont jamais vraiment effacées; elles sont libérées, c’est-à-dire qu’elles sont classées comme étant de l’information pouvant être écrasée. En d’autres termes, de la «mémoire vide». Donc, bp n’est pas vraiment vide; il contient plein d’informations laissées par d’autres utilisateurs. Des informations qui ont reçu l’autorisation d’être écrasées, mais qui peuvent être encore lues.

Dans un échange normal, les données provenant de pl sont mises dans bp dans une transaction d’un pour un, rendant la lecture de bp impossible, puisque le payload a défini la taille préalablement. En d’autres mots, si le payload défini un échange pl, bp de 64 Ko, il y aura un espace réécrit de 64 Ko dans bp, écrasant ainsi les anciennes données.

Là où est le problème de Heartbleed est qu’il est possible de dire n’importe quoi au serveur. Par exemple, si le payload est identifié comme 64 Ko et que pl est dans les faits 0 Ko, le serveur ira chercher 64Ko dans bp qu’il transfèrera. Comme pl ne contient rien, il n’écrasera pas le contenu avec du nouveau. Or, bp peut contenir beaucoup de choses, dont des identifiants numériques, des données financières, etc.

Il est important de mentionner que la faille Heartbleed permet d’accéder à 64 Ko de données. Ça semble bien peu, mais quand c’est du texte brut, ça peut contenir pas mal. En plus, comme on peut questionner le serveur souvent, ça peut commencer à faire une bonne quantité de texte brut.

Torrieux Gagnon, je ne comprends rien!

Cette allégorie, une pâle copie de celle proposée par Gizmodo, devrait être plus claire. Imaginez que vous avez 1 000 biscuits. Vous allez dans un magasin et la personne au comptoir est particulièrement stupide et ne sait pas compter – d’ailleurs, une chose que j’ai apprise en informatique, c’est qu’un ordinateur, c’est con.

Donc, vous arrivez au comptoir, vous foutez votre paquet de biscuits sur le comptoir et vous dites : «Heille le grand, j’ai 1 000 biscuits pour toé!» Le commerçant vous sourit d’un air niais et vous répond : «Ça adonne bien, j’ai une boîte pouvant contenir 1 000 biscuits.»

Le tapon sort donc une boîte de biscuits de son arrière-boutique et vous dit : «Voici la boîte! Bon, j’ai quelqu’un qui a mis 1 000 biscuits dans c’te boîte-là avant vous, mais ce n’est pas grave, je vais m’en débarrasser parce que personne n’en a besoin.» Le commerçant fout donc un biscuit aux poubelles, prend un de vos biscuits et le met dans la boîte. Il fait ça comme un grand champion jusqu’à ce qu’il ait terminé les 1 000 biscuits – bel après-midi, n’est-ce pas.

À la fin de ce processus, la boîte est donc pleine de vos biscuits, et les vieux biscuits sont dans les poubelles – notez d’ailleurs qu’ils ne sont pas détruits complètement; ils sont dans le sac-poubelle. Bref, un bel échange un pour un, tout le monde est content et les petits oiseaux chantent, etc.

Cependant, admettons que vous soyez un peu croche. Mettons que votre nom soit sorti fréquemment à la Commission Charbonneau. Vous arrivez donc au comptoir et vous dites au commerçant : «Salut capitaine! J’ai 1 000 biscuits pour toé!» Encore une fois, le commerçant sort une boîte qui accepte 1 000 biscuits bien remplis. Sauf que là, comme vous êtes ratoureux, au lieu de lui donner 1 000 biscuits, vous lui en donnez qu’un seul.

Comme dans l’exemple précédent, le vendeur prend un biscuit de la boîte qu’il sacre dans les poubelles, prend le vôtre et le remplace. Or, il n’en a qu’un seul et, comme il est particulièrement épais et qu’il est incapable de compter, lui il pense que son boulot est terminé. Il vous donne la boîte qui contient un de vos biscuits et 999 biscuits appartenant à quelqu’un d’autre – il va notamment en chercher dans la poubelle. Encore mieux, le vendeur est tellement zouave qu’il n’est même pas capable de faire la différence entre ce qui correspond à «zéro biscuit» et un nombre de biscuits qui ne correspond pas à zéro. En somme, il est con comme la lune et vous pouvez lui dire que vous avez des biscuits et ne pas lui en donner un seul. À tous les coups, le grand imbécile vous remettra une boîte pleine de biscuits.

Bref, tout ça pour dire que la faille Heartbleed implique qu’il est possible de mentir au serveur. Sauf que là, dans la réalité, ce ne sont pas des biscuits. Ce sont des données. La personne malintentionnée peut donc questionner le serveur jusqu’à ce qu’il donne des informations pertinentes, comme des identifiants numériques par exemple. D’ailleurs, cette bande dessinée de XQCD explique très bien le processus en arrière de Heartbleed.

Est-ce que cela signifie pour autant qu’OpenSSL n’est pas fiable? Non. En théorie, le protocole est fiable. Cependant, la gaffe dans le code a eu des répercussions importantes et lourdes en terme d’impact. Alors qu’on apprend que la NSA l’a exploité de nombreuses fois, force est d’admettre que cela aura des conséquences retentissantes sur la suite des choses.

Qu’est-ce que je peux faire pour me protéger?

Il faut tout d’abord que les sites web corrigent leur version d’OpenSSL. C’est l’administrateur qui doit le faire. De votre côté, il est important de changer vos mots de passe sur les différents sites web listés. Il existe aussi une extension pour Google Chrome, intitulée Chromebleed, qui vous permet de vérifier si les sites que vous visitez ont corrigé la faille.

Dur pour la communauté de développement en source ouverte

Au final, force est de constater que cela représente véritablement un œil au beurre noir pour la communauté de développement en source ouverte. Si plusieurs ont longtemps vanté la capacité de la communauté à faire du code propre et sécuritaire, Heartbleed vient de remettre en question – et de manière disgracieuse – cette assertion. Par contre, comme la sécurité parfaite n’existe pas et n’existera jamais, peu importe qui fera le développement, on finira tôt ou tard par voir ce genre d’événement se produire. Car, la problématique principale est la dépendance aux technologies et le fait qu’elles soient de plus en plus standardisées.

Je tiens à remercier certains anciens étudiants de la Polytechnique qui m’ont aidé à ne pas dire trop de niaiseries dans ce texte. Vous allez vous reconnaître.