Vilaine LEN...
J'avoue. La LEN ne m'intéresse que moyennement. C'est devenu un tel serpent de mer, ce projet de loi change de nom tous les trois jours, il est discutée et rediscutée par les deux chambres du Parlement, bref, on en voit pas le bout. Ou si, on en voit le bout. Encore une loi qui tente d'encadrer ce réseau mondial qu'est Internet. Depuis sa révélation au grand public, les autorités et les grands groupes internationaux ont tenté de le contrôler. Les unes avec des lois, les autres avec des dollars et de la technologie. Il faut dire que ça fait peur un machin comme ça. C'est totalement (ou presque) décentralisé, ça donne la parole à l'ensemble de la population qui y est connecté, ça permet à des groupes de pression de se fédérer et, accessoirement, cela peut devenir un levier puissant pour renverser des empires. Alors voici la LEN, ou quel que soit son nom. Une loi qui va, si l'on en croit les commentaires que l'on peut lire ici ou là, jusqu'à interdire la publication de bugs. Je ne peux que me fier aux commentaires variés parce que pour une fois, je n'ai pas suivi le détail des discussions législatives autour du texte. Je n'y vois aucun intérêt. Je présume que quel que soit le barrage des associations luttant pour la liberté d'expression, le texte sera voté et sera répressif. Il y a des choses inéluctables. On peut le regretter mais pas grand chose de plus. Sauf à se confronter à une déperdition des efforts fournis dans la lutte. Cela est déjà arrivé pour le Traité sur la cybercriminalité du Conseil de l'Europe. Ceci dit, le contenu du texte étant, comme souvent, éloigné de la réalité et des spécificités techniques du réseau et de ses composants, ne tenant pas compte de la nature intrinsèquement décentralisée et internationale d'Internet, quelques débats de religion remontent à la surface médiatique.
C'est le cas de la publication de bugs ou de la conservation des logs.
Les sénateurs ont paraît-il, à ce stade de la discussion, décidé de laisser à l'appréciation du juge s'il y avait un « motif légitime » à « détenir, offrir, céder ou mettre à disposition un instrument, programme informatique ou toute donnée conçus ou adaptés » pour « introduire frauduleusement des données dans un système de traitement automatisé », « supprimer ou modifier frauduleusement les données qu'il contient ». Un hacker a-t-il, aux yeux de la justice, « un motif légitime » a annoncer publiquement qu'un logiciel ou un matériel informatique contient un défaut mettant en danger la sécurité de ses utilisateurs ? Le texte laisse la réponse ouverte. Ce sera au cas par cas... Les associations s'inquiètent du fait que la publication de travaux en matière de sécurité informatique ne sera plus possible. A juste titre.
La plupart des chercheurs (ça change de hacker comme terme non ?) publient, en plus d'un argumentaire technique, un bout de code permettant d'exploiter la faille qu'ils ont découverte. L'idée est de démontrer, preuve à l'appui, que l'on peut effectivement profiter du bug découvert pour faire faire quelque chose d'inattendu, et probablement de dangereux (sur le plan de la sécurité des utilisateurs) au logiciel ou au hardware étudié. C'est ainsi depuis la nuit des temps. Avec cette nouvelle loi, il sera effectivement très risqué de publier une faille et/ou un proof of concept (le bout de code en question).
Maintenant, poussons la discussion un peu plus loin.
Jusqu'ici, nous sommes dans le débat suivant : « le législateur doit-il interdire la recherche dans le domaine de la sécurité informatique ? ». Passons à : « la publication dans le domaine de la sécurité informatique est-elle une démarche qui bénéficie à la communauté des utilisateurs ou pas ? ».
On peut rêver d'un monde cyber où tous les éditeurs proposeraient des versions corrigées de leurs logiciels quelques jours avant ou simultanément à la publication d'un bug (façon RFPolicy). D'un monde où chaque administrateur mettrait à jour les logiciel ou le hardware dont il a la charge. Et ce, le jour de la publication du correctif. On peut rêver d'un monde ou tout le monde serait un adepte du concept de « full disclosure », celui-là même qui consiste a encourager la publication de toutes les failles afin de forcer les éditeurs à améliorer leurs produits. En effet, si certains n'en sont pas partisans et conservent leurs trouvailles pour leur usage personnel, il y a des failles qui ne seront pas corrigées et qui seront probablement exploitées.
Mais ce monde a un défaut. Il était presque parfait il y a quelques années lorsque les gros groupes craignaient pour leur image lorsqu'un hacker postait une faille dans Bugtraq. Le dialogue entre hackers et gros éditeurs devenait possible sur le mode « de toutes façons, tu répares ou pas, moi je rends publique la faille dans Bugtraq ». Généralement, les gros éditeurs réparaient et remerciaient même parfois l'auteur du post de son intérêt pour le logiciel. La reconnaissance était un deuxième combat qui a vite été remporté... La configuration générale pour que le « full disclosure » soit bénéfique pour l'ensemble des utilisateurs était bonne a ce moment-là. Simplement parce que la proportion d'utilisateurs pouvant utiliser à des fins négatives les travaux des chercheurs était faible. Aujourd'hui, la proportion de gens qui utilisent ces failles pour pourrir la vie des autres utilisateurs a grossi considérablement. A tel point que l'on peut raisonnablement se demander si la publication de failles et autres « exploits » (dieu que ce terme est affreux...) ne contribue pas plutôt à rendre le cyber-monde moins sûr.
Prenons un exemple : eEye. Kitetoa.com aime beaucoup Marc Maiffret, fondateur et Chief hacking officer de cette société de sécurité informatique. Nous nous connaissons depuis des lustres. Ceci dit, il n'y a pas de discussion possible, la plupart des bugs publiés par eEye sont à la base de la plupart des virus et autres vers qui ont circulé ces dernières années. Bien entendu, Marc Maiffret ne voulait pas que les travaux de recherche de son entreprise servent à cela. Mais c'est ce qui s'est passé. Pourtant, eEye publie généralement en concertation avec Microsoft (l'éditeur le plus concerné dans cette histoire). Combien de « Code Red » faut-il pour remettre en cause le concept de « full disclosure » ?
C'est à peu près à cette époque là que le concept d'Obscurity a été promu par ADM et Security.is sous le nom de « AntiSecurity ». Ces hackers estimaient qu'il était grand temps de mettre un terme à la spirale infernale publication de bugs/publication d'exploits/defacements/mises à jour/etc. Certains de leurs arguments tennaient tout à fait la route. Ils ont été raillés par les tenants du « full disclosure ».
Il ne s'agit pas d'interdire la publication de failles, ce qui serait en soi une idiotie (la prohibition, ça ne marche pas très bien, il vaut mieux affronter les causes des problèmes plutôt que de d'enfermer ces derniers dans un placard), mais plutôt d'encadrer les procédures liées à cette publication. Là où la RFPolicy a ouvert le chemin, le législateur pourrait probablement poursuivre la réflexion. Une piste intéressante et systématiquement écartée de ce genrte de débat est la responsabilité des entreprises qui commercialisent des produits défaillants... De même, le combat contre les logs et leur conservation est probablement un combat perdu d'avance. Il ne serait pas être pas idiot de concentrer les forces des associations sur l'usage qui pourra être fait de ces logs. Et dans quel cadre.