juin 10th, 2014

Un an jour pour jour après la publication des toutes premières fuites concernant Prism, le « contrat de confiance NSA » qui liait les principaux éditeurs US à l’agence de renseignement, Microsoft demande une réforme des pratiques de la No Such Agency et réclame que les éventuels mécanismes d’écoute et de déchiffrement s’arrêtent aux frontières des Etats-Unis, nous informent nos confrères de Network World. Cette trop grande surveillance pourrait avoir des conséquences néfastes sur le business et la confiance accordée aux produits commercialisés par l’éditeur.

Aux frontières des USA, entendons par là que Microsoft tolère les écoutes de la NSA au-delà desdites frontières, et ne formule sa prière que pour ce qui concerne le territoire fédéral. Le fait de barbouzer les clients « étrangers » que nous sommes ne semble pas particulièrement impacter la confiance desdits clients. Après tout, lorsque plus de 98 % des outils diffusés dans le monde sont sous le contrôle de AOL, Apple, Dropbox, Facebook, Google, LinkedIn, Microsoft, Twitter ou Yahoo, on craint nettement moins les risques de désaffection au profit d’un concurrent mort depuis longtemps.

Deux communiqués successifs préviennent d’un grave défaut l’un dans OpenSSL, l’autre dans la bibliothèque de fonction GnuTLS. La première, portant l’immatriculation CVE-2014-0224, ouvre la voie à une possible attaque « man in the middle ». Ce problème serait endémique et remonterait au moins aux éditions datant de 1998. Le second trou, concernant GnuTLS, est référencé CVE-2014-3466, et appartient à la famille des buffer overflow. Peut en découler une exécution de code arbitraire en mémoire ou un crash système. Les nouvelles versions 3.1.25, 3.2.15 et 3.3.4 corrigent cette erreur précise le bulletin d’alerte.

Lorsque l’équipe de développement de Truecrypt a annoncé l’arrêt brutal du développement de cet outil de chiffrement multiplateformes, les pires suppositions ont fusées, tant dans la presse que sur les blogs. Suppositions d’autant plus alarmistes que la première phrase, marquée au fer rouge en tête de page, ne laisse place à aucun doute « WARNING: Using TrueCrypt is not secure as it may contain unfixed security issues ». De là à se demander, par simple réflexe post-snowdenien, si ces « security issues », et plus particulièrement d’éventuels erreurs d’implémentations plus ou moins volontaires, n’auraient pas été provoquées.

Pourtant, comme le fait remarquer Hervé Schauer, au fil de sa lettre d’information mensuelle, Truecrypt a été audité maintes et maintes fois : une initiative de l’Open Crypto Audit, deux audits CSPN en France comme le rappel un communiqué de l’Ansi. Lequel Ansi, au passage, recommande la migration vers d’autres solutions de chiffrement, toutes « closed sources » et commerciales.

Pour l’heure, donc, Truecrypt doit être considéré comme relativement fiable, et si l’on ne craint pas d’être la cible des attentions particulières de la NSA, et il est urgent de ne pas paniquer. Particulièrement pour ce qui concerne les personnes exploitant différentes versions (Windows/Linux/OSX) du programme. Un fork Helvétique devrait permettre aux inconditionnels de ce programme open source de perdurer encore.

Il y a un peu plus de 4 ans, David et Robert Maynor s’offraient un émetteur-récepteur logiciel (SDR) et entamaient un long travail de fuzzing dans le domaine du sans-fil. Rien n’est gratuit. Car contrairement à une faille Heartbleed qui ne parvient à émouvoir qu’un tout petit cénacle de spécialistes du chiffrement, les hacks radio « parlent » aux oreilles de la presse, et touchent notamment la dernière marotte des politiques en mal de popularité : l’internet des objets. Et c’est donc sur le thèmes « objets interconnectés, avez-vous donc une RAM que je puisse exploiter » que Bob Graham s’interroge sur la divulgation (ou non) d’un exploit radio visant les stimulateurs cardiaques, alias pacemakers. Et de décrire par le menu ce drame cornélien du chercheur qui trouve, et dont la découverte (ou plus exactement la publication de sa découverte) pourrait avoir pour conséquence extrême la mort de porteurs de ce genre d’appareil.

Outre le fait que ce genre de travaux s’opère généralement « en chambre », avec des niveaux de puissance ridicules, des distances de liaison se comptant en décimètres, et une totale absence de tests « grandeur réelle » en milieu urbain perturbé et à grande puissance/distance, on peut se demander si ce genre d’introspection blogo-sécuritaire ne frise pas la provocation. Certes, le domaine médical, à l’instar du secteur de l’automatisme industriel, a vécu, des années durant, avec l’absolue certitude que les techniques touchant à la radioélectricité relevaient de la sorcellerie et de la haute technologie, « inaccessible au commun des mortels ». Une forme de sécurité par l’obscurantisme en quelques sortes. Mais pour ce qui concerne le choix éthique du chercheur (dois-je ou ne dois-je pas communiquer le résultat de mes recherches à l’occasion d’une conférence technique telle que la DefCon), la question peut-elle sérieusement se poser ? Pour quelle raison existerait-il deux poids, deux mesures, entre le monde logiciel et le monde médical ? Le « full disclosure » raisonné, avec communication préalable auprès des éditeurs, correction des bugs puis divulgation après un laps de temps nécessaire au déploiement de correctifs est devenu une quasi-norme de nos jours. Tout comme est devenue une quasi-habitude le fait de rémunérer correctement les chercheurs ayant fait l’effort de découvrir et d’analyser une faille de sécurité. Que la cible soit un instrument médical ne change rien à l’affaire. A moins… à moins que cette industrie n’ait pas coutume de raisonner en termes de « fenêtre de vulnérabilité », de « calendrier de correction », de « campagne de déploiement de correctifs »… ou de barème publié de « bug bounty ».

Et c’est peut-être là le principal iatus.

Lorsqu’en 2009 Alex Sotirov, Dino Dai Zovi et Charlie Miller ont, à l’occasion de CanSecWest, entamé leur campagne « no more free bugs », ils s’adressaient à une profession d’éditeurs directement impliquée dans le développement de logiciels et firmwares. Langage d’informaticiens pour des informaticiens. Aujourd’hui, ce discours peut-il être entendu par les industries de l’automatisme, du contrôle de processus, de l’équipement médical, des équipementiers de la grande distribution, des secteurs financiers, automobiles, aéronautiques ? … Bref, de tous ceux qui, sans appartenir au monde du développement logiciel, développent leurs propres programmes ? Et lesdits industriels seront-ils enclins à récompenser ces chercheurs en cas de découverte d’un bug majeur, sans considérer ladite recherche comme une tentative de racket ?

La véritable question que pose Robert Maynor va bien au-delà du simple problème du full disclosure or not full disclosure. Elle interroge l’ensemble des secteurs d’activités qui, par un biais ou par un autre, ont numérisé leurs outils et applications, et n’ont pas toujours pris en compte la dimension infosec. Ni budgétisé les coûts induits… remerciements aux chercheurs y compris. Un « à votre bon cœur » qui s’annonce avec un hack de pacemaker, voilà qui atteint des sommets lacaniens.