Close
  • Français
  • English

15/05/2014Heartbleed [Par Maitre Stéphane Choisez, cabinet NCA et Hugo Lemarchand, CEIS]

« Catastrophic is the right word. On the scale of 1 to 10, this is an 11[1] »

Bruce Schneier

Heartbleed est sans aucun doute une faille la plus grave qu’internet aura connu à ce jour, et dont les conséquences importantes se sont déjà faites ressentir : si le gouvernement canadien a annoncé que plus de 900 numéros d’assurance sociale ont été dérobés grâce à l’exploitation de cette faille du système SSL[2], beaucoup d’entreprises détenant des données à caractère personnel de leurs clients ont du prévenir ces derniers afin qu’ils changent en urgence leurs mots de passe, à l’image de Darty qui a contacté l’intégralité de ses clients à cet égard[3].

L’origine de la faille Heartbleed : une erreur de code

Pour comprendre l’importance d’Heartbleed, il convient tout d’abord de comprendre ce qu’est le système SSL. Ce procédé, dont l’acronyme signifie Secure Sockets Layers, est utilisé pour sécuriser les échanges entre serveurs et garantit notamment l’authentification du serveur, la confidentialité et l’intégrité des données échangée. Du fait que le système SSL soit indépendant du protocole employé[4] (HTTP pour le Web ou POP ou IMAP pour les emails par exemple), il est utilisé par énormément de services internet.

Quand deux ordinateurs sont sur le point d’entreprendre un échange sécurisé, un processus intitulé « Heartbeat » (à l’origine du nom de la faille), se met en place : il a pour fonction de vérifier que chacun des interlocuteurs reste en contact permanent : si l’un des deux cesse d’émettre, l’autre fera de même immédiatement, évitant ainsi que des données soient envoyées à un autre destinataire que celui authentifié.

Image 1

memcpy : commande litigieuse dans la faille Heartbleed
bp : destination finale des informations
pl : emplacement initial des informations
payload : taille des informations

Illustration 1. Extrait du code du système SSL – Source : klocwork.com[5]

Image 2

 La faille Heartbleed réside dans une erreur de code du système SSL[6]. La commande « memcpy », en rose dans la capture d’écran ci-dessus, sert à copier les informations échangées. Pour se faire, elle a besoin de trois renseignements : la destination finale des informations copiées (« bp »), l’emplacement initial des informations en question (« pl ») et la taille des informations (« payload »). Logiquement, la taille de l’espace créé pour la destination finale des informations (pl) devrait être la même que celle de l’emplacement d’origine des informations. Et les données contenues dans cette espace sont écrasées chaque fois que des nouvelles données sont reçues.

La faille Heartbleed a pour conséquence de tromper le serveur sur la taille des données reçues : si l’on fait croire au serveur que la taille des données reçues est supérieure à celle des données réellement envoyées (qui est nulle dans le cas de Heartbleed), les données préalablement enregistrées ne sont donc pas écrasées et peuvent ainsi être récupérée par la suite.

L’exploitation de cette faille consiste donc à interroger le serveur jusqu’à temps qu’il communique des données intéressantes pour l’exploitant[7], comme des identifiants de compte ou des données bancaires.

Source : xkcd[8]

Une porte ouverte pour les attaquants et l’effondrement de la confiance des utilisateurs

Le site Pastebin, qui permet d’échanger des extraits de textes et notamment du code source, aurait vu circuler pas moins de 10 000 noms de domaines vulnérables à ladite faille[9]. Car si la plupart des sites vulnérables référencés le sont pour une cause louable, à savoir la correction de la faille, des personnes malintentionnées s’en servent aussi pour préparer des attaques. Des pirates ont également mis en vente un kit destiné à exploiter cette faille pour une somme de 2,5 bitcoins[10].

De son côté, la NSA, bien qu’elle réfute fermement l’utilisation de cette faille à d’espionnage et de surveillance, est également soupçonnée d’en avoir eu connaissance depuis 2 ans et de l’avoir largement utilisé. Les agences américaines sont toutefois autorisées par la Maison Blanche à exploiter les failles découvertes[11].

De nombreux outils ont été mis à disposition[12] sur le web afin de savoir si un nom de domaine était vulnérable à la faille, qui existe depuis 2 ans déjà, comme l’outil Heartbleed Checker mis à disposition par l’éditeur de solutions de sécurité McAfee ou l’extension Chromebleed pour certains navigateurs (Google Chrome, Firefox et Opera).

Une autre conséquence de la faille Heartbleed est la perte de confiance des utilisateurs dans l’usage d’internet : alors qu’il est très difficile de communiquer sur des normes de sécurité auprès du grand public, il était acquis depuis quelques temps que la présence du petit cadenas ou du « s » à la fin de « http » dans l’URL était gage d’un site sûr. Heartbleed vient donc remettre en cause cette impression de confiance chez les utilisateurs et nous rappelle qu’un internet sûr et sécurisé n’existera jamais.

En réponse à cette faille, la fondation Mozilla a revu sa politique de confiance vis-à-vis des certificats, en empêchant « l’utilisation abusive d’autorités de certification subordonnées ou intermédiaires susceptibles de fournir des certificats SSL sur n’importe quel domaine Internet »[13].

De plus, alors que l’Open Source a toujours été gage de sécurité, la faille Heartbleed remet en question cette affirmation. En France, l’April, une association qui œuvre pour la démocratisation et la diffusion du logiciel libre, s’oppose à un jugement trop hâtif sur la fiabilité du logiciel libre. Elle souligne d’ailleurs que c’est justement le caractère libre du code qui a permis d’éviter des conséquences plus catastrophiques : « c’est même l’analyse du code lui-même, en voulant y ajouter de nouvelles fonctionnalités, qui a permis la détection de l’erreur. Ensuite, la correction a pu être immédiatement proposée par et à la communauté, le code-source étant une nouvelle fois disponible » [14].

Image 3

L’équipe du projet openBSD, un système d’exploitation libre de type Unix, a en outre lancé un fork[15] d’OpenSSL appelée « LibreSSL »[16]. Ce projet a pour objectif de corriger et d’améliorer OpenSSL, notamment grâce à un « nettoyage » du code qui contient des caractères superflus accumulés au fil des versions.

En outre, les poids lourds du numérique, qui utilisent largement le système SSL au sein de leurs services – et dont l’impact sur leurs clients pourraient être considérable – ont également réagis : Microsoft, IBM, Google, Facebook, VMware et huit autres grands noms de l’IT ont rejoint l’initiative Core Infrastructure[17], supportée par la fondation Linux, qui vise à renforcer la sécurité des projets Open Source les plus sensibles et vulnérables.

Quid de la responsabilité ?

Tenter de trancher le problème de la responsabilité de façon rapide et intuitive revient immanquablement à se tromper sur la façon dont le Droit de la Responsabilité peut appréhender la faille Heartbleed.

Serait ainsi responsable le développeur qui aurait, par mégarde, tenté d’amélioré le logiciel OpenSSL.

Pourtant raisonner ainsi est un non-sens car l’on ne tient pas compte de la spécificité des logiciels libres ou en « Open Source ». Le logiciel libre s’appuie sur une approche quasiment philosophique de la diffusion du logiciel qui autorise, quand un auteur d’un logiciel libre décide de le mettre sur le marché, l’utilisateur à exécuter le programme, à en étudier le fonctionnement et donc avoir accès aux sources du programme mais également et surtout confère à cet utilisateur la liberté de le modifier, et concomitamment la liberté de le redistribuer.[18]

Et le Juge Français parait bien valider le principe de la licence dite libre[19], considérant notamment que l’utilisateur de la licence libre doit respecter les obligations imposées par les licences libres, interdisant ainsi de faire disparaitre « des copyrights d’origine de VNC sur les propriétés de deux fichiers en les remplaçant par les siens ». Mais le Juge Français validerait-il pour autant le principe, sous-jacent mais récurrent, amenant à considérer que l’utilisateur d’un logiciel libre sera tenu de prendre le logiciel libre tel qu’il est, à charge pour lui de l’aménager et de le modifier ?

Cette question, qui relève plus de la morale que du droit, ne peut toutefois recevoir de réponse précise. Qui est alors responsable d’un logiciel libre défaillant ?

Son concepteur ? Qui, dans l’esprit du logiciel Open Source, et par inadvertance, ne voit pas la faille qu’il élabore dans certaines versions du logiciel Open SSL, sur lequel s’appuie pourtant une immense partie de la sécurité du web.

Son utilisateur ? Qui, précisément en matière de sécurité, fait confiance au logiciel Open Source et se voit tout aussi incapable d’identifier la faille de sécurité ?

On voit donc se dessiner une chaîne de responsabilité dont le maillon le plus faible ne sera peut-être pas, paradoxalement le plus évident, c’est-à-dire le développeur du système SSL affecté par la faille Heartbleed.

En effet, la loi du 6 janvier 1978[20], dite informatique et liberté, pose en son article 34 un principe curieusement peu usité par le droit positif mais qui rappelle que le responsable du traitement est tenu de prendre « toutes précautions utiles, au regard de la nature des données et des risques présentés par le traitement, pour préserver la sécurité des données et, notamment empêcher qu’elles soient déformées, endommagées ou des que des tiers non autorisés y aient accès. »

La législation française invite donc, au premier chef, chaque responsable de traitement à être le premier responsable à l’égard de sa clientèle de la défaillance Heartbleed, et à tout faire pour que la faille de sécurité soit comblée.

La CNIL s’est d’ailleurs clairement emparée du sujet et a dans une communication du 16 avril 2014[21] rappelé comment réagir à une faille de sécurité telle que Heartbleed, imposant notamment de mettre à jour les serveurs vulnérables, de révoquer les clés et certificats utilisés, de renouveler les clés et de mettre à jour les certificats correspondants et de conseiller aux utilisateurs de renouveler leurs moyens d’authentification, et plus précisément leurs mots de passe.

Aux yeux des juges, le premier responsable de la faille Heartbleed pourrait bien être l’entreprise utilisatrice du logiciel défaillant.

Un recours limité et illusoire

Mais, théoriquement, l’entreprise utilisatrice pourrait se retourner contre le concepteur du logiciel libre. Cette stratégie apparait pourtant plus logique que réellement pertinente car s’il est en effet logique de faire faire remonter une chaîne de responsabilité au premier maillon défaillant, il s’agit que l’objet du recours puisse non seulement être identifié mais surtout solvable.

Or, le logiciel source prospère sur une communauté plus ou moins informelle, plus ou moins désignée, mais ne disposant certainement pas des moyens des entreprises multinationales qui ont utilisé les versions du logiciel Open SSL défaillantes. Quand bien même cette entreprise, française par exemple, tenterait de remonter la chaîne de responsabilité via un recours, elle se heurterait tout d’abord à des redoutables problèmes de droit international privé.

Sans compter que dans la plupart des licences open source (GNU GPL), il est bien spécifié que la licence « comes with no warranty ». Or, on sait, depuis un arrêt de la chambre commerciale de la cour de cassation du 29 juin 2010[22], qu’une clause limitative de réparation est juridiquement valable sauf si elle « contredit la portée de l’obligation essentielle souscrite par le débiteur ».

Mais, formellement l’obligation essentielle souscrite par le débiteur, c’est-à-dire ici le concepteur et/ou développeur du logiciel Open Source, est de transmettre […] un logiciel en Open Source, à charge pour les utilisateurs de l’améliorer. On peut donc imaginer qu’au regard du droit français, une telle clause limitative de responsabilité pourrait être déclarée valable ce qui, concernant la question d’un recours d’un utilisateur du logiciel SSL défaillant, rendrait ce recours très difficile.

On le voit donc, la responsabilité induite par l’affaire Heartbleed risque paradoxalement de peser bien plus sur les épaules de l’utilisateur du logiciel Open SSL que sur son développeur. En somme, l’utilisateur du logiciel en open source SSL serait responsable d’avoir « trop » fait confiance à la communauté open source et à ses engagements généreux, ce qui serait une leçon de droit pour le moins originale.

Par Maitre Stéphane Choisez, cabinet NCA et Hugo Lemarchand, CEIS. 


[15] Logiciel créé à partir du code source d’un logiciel existant : LibreOffice a été lancé à partir d’OpenOffice par exemple

[18] Voir le commentaire de Sandrine RAMBAUD – in Revue LAMY DROIT DE L’IMMATERIEL 2009 n° 54

[19] Pour la licence GNU GPL version 2 ; Cour d’Appel de Paris du 16 septembre 2009 – Pôle 5 – chambre 10 – septembre 2009 SA EDU / Association AFPA

[20] Loi n° 78-17 du 6 janvier 1978

[21] Sur son site www.cnil.fr

[22] Décision dite FAURECIA 3 – JCP E – 16 septembre 2010 n° 37