Spécial sécurité : Microsoft s'éloigne du dogme de la "divulgation responsable" des failles
Aujourd'hui, nos confrères de CNIS, magazine spécialisé dans la sécurité des systèmes d'information, s'attardent sur l'évolution de la position de Microsoft en matière de divulgation de vulnérabilités. Une évolution qui vise à rapprocher les positions de l'éditeur de celles des partisans du "Full Disclosure". L'occasion également de faire un point sur le business de la découverte de faille. Où quand le "bug business" devient un big business...
Sommaire
1 - Divulgation des vulnérabilités (Partie I): Microsoft assouplit son attitude
2 - La bataille de la divulgation (Partie II) : Le nerf de la guerre
1 - Divulgation des vulnérabilités (Partie I): Microsoft assouplit son attitude
La « divulgation responsable » est morte, vive la « divulgation coordonnée des vulnérabilités » (CVD). Un article sur le blog du MSRC, prévient de la publication d’un papier fondateur rédigé par Katie Moussouris (senior security strategist de l’équipe Ecosystem Strategy du MSRC) et co-signé par un aréopage de confrères et gourous de la sécurité travaillant au Mitre, dans divers Certs du monde entier, chez Juniper, Intel, Tenable, Cisco, iDefense-Verisign, Paypal, Veracode… l’on y trouve même des noms de grands « divulgateurs », tel Dino Dail Zovi ou Jeremiah Grossman.
Que raconte ce mémorandum ? Que le CVD remplacera le précédent mode de divulgation. En outre, le mot « responsable » est définitivement banni du vocabulaire Microsoftien. Auparavant, il existait schématiquement deux formes de divulgation : tout d’abord le FD (Full Disclosure, divulgation libre et rapide), débridé et anarchique, qui prône l’accès public à toutes informations concernant une faille dès qu’elle est découverte, sans préséance aucune pour un organisme ou une entreprise en particulier. Venait ensuite le RD, ou Divulgation Responsable, qui garde secrète l’information tant que l’éditeur (et lui seul) n’a pas estimé le niveau de dangerosité du défaut et n’a pas corrigé puis déployé la rustine colmatant le trou découvert. Tout chercheur partisan du FD ou de toute autre politique de révélation est ipso-facto qualifié « d’irresponsable »… autrement dit, au sens étymologique du terme, frappé d’une forme de démence clinique telle qu’il n’est plus responsable de ses propres actes. L’on se demande alors, puisque l’irresponsabilité est invoquée, pour quelle raison les services juridiques sont parfois brandis à l’encontre de certains chercheurs… Les personnes frappées de maladies mentales sont-elles juridiquement responsables dans l’Etat de Washington ? Quand on pratique la Novlangue, il faut savoir en accepter toutes les implications et toutes les contraintes sémantiques …
Outre le fait que cet argument accusant un chercheur de folie rappelle par certains aspects la phraséologie des régimes politiques dictatoriaux, il force tout chercheur en sécurité à se plier aux fourches caudines de l’éditeur, seul responsable auto déclaré à la fois de l’évaluation de la criticité de la faille et du délai de correction nécessaire. « Certains trous sont excessivement difficiles à corriger, et qu’une régression (bug provoqué par le correctif), même si elle ne touche qu’un petit pourcent de la clientèle, peut faire souffrir des milliers de personnes. Notre statut de concepteur du logiciel incriminé fait de nous la seule et unique entité capable d’estimer le temps de correction et le seul organisme habilité à corriger proprement ledit trou de sécurité.».
Tout çà va changer avec le CVD. Désormais, Microsoft n’est plus le seul dépositaire du « secret ». La révélation de la faille pourra s’opérer par tout tiers de confiance, tel qu’un Cert, un Mitre et ses classifications CVE ou un organisme commercial faisant profession d’acheter du trou à partir du moment où celui-ci en communique la teneur en priorité à l’éditeur : le ZDI de HP par exemple. Ce qui interdit semble-t-il toute révélation directement opérée par l’inventeur de la faille.
En outre –et c’est là le point probablement le plus important-, cette charte inclut la possibilité d’une « communication coordonnée » auprès du public dès lors qu’il est prouvé que la faille est activement exploitée. Finie l’omerta du « bug non corrigé » lorsque tombent dru les virus exploitant une faille connue. Enfin, un appel du pied est fait à l’attention des partisans du Full Disclosure. Katie Moussouris écrit « we respectfully disagree, but we still want to work with you ». En d’autres termes, « nos opinions politiques divergent, ce n’est pas une raison pour couper le dialogue ». Le chercheur partisan du FD ou d’une politique de divulgation moins inféodée au bon-vouloir de l’éditeur n’est plus qualifié d’irresponsable, le port de l’entonnoir n’est plus obligatoire dans les allées de la Defcon. Quoiqu’imparfaite soit cette prise de position, elle marque une très nette évolution dans la psychologie « corporate » de Microsoft. Cet effort est d’autant plus louable que lorsque Microsoft prend position, c’est toute la profession qui emboîte le pas. Mais cela suffira-t-il ?
L’un de ces anciens « dangereux irresponsables » récemment classé dans le top ten mondial des inventeurs de failles les plus prolixes, le Luxembourgeois Thierry Zoller, publiait il y a quelques temps déjà sa propre charte de divulgation, précise et surtout argumentée, avec un constat regrettable : lorsque l’initiative de la divulgation est confiée à un éditeur, celui-ci prend systématiquement le parti d’étouffer l’affaire. Et Thierry Zoller de témoigner « From the 800 vulnerability notifications I send in the last 2 years, 3 (!) were published by vendors voluntarily ». A peine 0,4%... En admettant même que Microsoft soit un modèle du genre en matière de réactivité et de négociation –ce que contestent bien des chercheurs- ce chiffre prouve que ce même Microsoft ne peut servir de garantie pour l’ensemble de la profession d’éditeur de logiciels. Une exception ne confirme jamais une règle en matière de sécurité. La politique du « meilleur effort » pratiqué par une poignée de « software companies » et d’équipementiers consciencieux ne doit pas masquer la mauvaise volonté –ou l’incapacité- endémique de 90% du reste de la profession.
C’est précisément cette quasi-certitude de voir ses recherches occultées qui aurait poussé Tavis Ormandy à révéler, début juillet, le bug du protocol Help Center. Un Tavis Ormandy employé de Google, qui enfonce un peu le clou en invoquant l’urgence d’une communication « ouverte et publique » en cas d’exploitation ou de communication « dans la nature ». Car au manifeste CVD de Microsoft, le Response Team de Google réplique avec une toute autre prise de position, en alignant tout son staff sécurité : Michal Zalewski, Chris Evans, Eric Grosse, Matt Moore, Julien Tinnes… des noms très connus, généralement rencontrés sur la mailing list Full Disclosure. Et le « Responsible Disclosure » d’en prendre plein son grade. L’argument « Microsoft sert d’alibi à tous les éditeurs de mauvaise volonté » revient sur le tapis : « Nous avons vu un nombre croissant d’éditeurs invoquer le principe du RD pour retarder indéfiniment la correction de bugs, parfois durant des années. Durant ce laps de temps, ces failles ont souvent été redécouvertes par des chercheurs nettement moins honnêtes, en employant des méthodes et des outils identiques à ceux utilisé par les chercheurs « blancs » » et de préciser peu après « Parallèlement, nous croyons que la Divulgation Responsable est une voie à double sens. Les éditeurs, aussi bien que les chercheurs, doivent agir de manière responsable. Des bugs sérieux doivent être corrigés dans un laps de temps raisonnable »…. Google est un éditeur, et faire preuve d’une attitude trop radicale pourrait se retourner contre ses propres pondeurs de code. « Bien que chaque bug soit unique, l’on peut penser qu’un délai de 60 jours constitue la limite maximale raisonnable pour corriger un problème critique découvert dans un programme largement utilisé ». Deux mois : un délai long, mais au moins une limite précise, et non plus une clause floue laissant à l’éditeur toute latitude d’action… ou d’inaction. Rappelons tout de même que, des dires même de Tavis Ormandy, le délai écoulé entre l’avertissement fait à Microsoft et la divulgation du bug « Help Center » n’a pas dépassé 5 jours. Le moins que l’on puisse dire, c’est que l’attitude d’un Google Security Team donnant des leçons de déontologie à Microsoft relève plus de la provocation que du concours d’élégance de Saint Cloud.
Google marque un point tout de même en insistant sur le fait que Microsoft ne peut, sur ce sujet, parler en son nom propre. Tout ce que dira la Windows Company a été et sera pris comme modèle et comme référence… En se prononçant pour ou contre telle ou telle solution, Microsoft parle, qu’elle le veuille ou non, au nom de toute une profession, et s’engage au nom de tous. C’est la rançon du titre de leader. Par conséquent, toute prise de position tranchée émise à Redmond sera interprétée comme un diktat ou comme une règle-alibi. Ergo, tout ce que pourra décider Microsoft de sa propre initiative sera critiquable, car biaisé par d’évidents conflits d’intérêts. Il y a un peu de vrai là-dedans.
Là ou Google commet une erreur, c’est en se faisant critique sans proposer de solution plus brillante. Car pour quelle raison Google, également éditeur, également juge et partie, aurait « plus raison » que son concurrent direct ? La vérité, si elle existe, doit nécessairement se trouver du côté d’une sorte de « force d’interposition », ne faisant ni partie de l’industrie, ni favorable aux opinions des chercheurs indépendants. Microsoft a failli atteindre un tel but, en proposant il y plusieurs années un « draft IETF » sur le sujet. Draft rapidement retiré du cycle des RFC lorsqu’il a été compris que la situation aurait pu échapper à l’éditeur. C’est pourtant par le truchement d’un organisme neutre que pourrait le mieux se voir défini un calendrier précis des divulgations et des délais de correction maximaux. Jamais la divulgation ne pourra faire l’objet d’une législation internationale au sens stricte du terme… ce qui ne veut pas dire qu’il soit impossible de voir naître un consensus général sous la houlette d’une organisation elle-même internationale.
2 - La bataille de la divulgation (Partie II) : Le nerf de la guerre
Mais plus que des histoires de « responsabilité » face à des hordes potentielles de pirates cachées derrière chaque publication de faille, le véritable problème de la divulgation « full, responsable ou coordonnée », c’est avant tout une histoire d’argent.
A quelques ZDI près, rares étaient autrefois les gens capables de payer honnêtement les chercheurs en sécurité découvrant une vulnérabilité. Situation qui donnait à ces derniers le droit moral d’utiliser à leur guise le fruit de leur travail : « J’ai trouvé, je ne suis pas payé de mes efforts, je fais donc ce que bon me semble de mes découvertes, et si possible sous forme de publicité pour le compte de mon entreprise ». Argument souvent suivi d’un « si vous souhaitez en savoir plus ou obtenir un PoC fonctionnel, payez moi ou laissez-moi tranquille, et estimez-vous heureux que je n’ai pas déjà vendu mes découvertes à quelque cyber-truand Russe, Chinois ou Brésilien ». A quelques variantes près, l’on a pu lire ces propos sous la plume de http-equiv, Paul de Greyhat (avant sa conversion), Joanna Rutkowska, les frères Lietchfield…
Cette attitude s’est d’autant plus développée que la cyberdélinquance s’est, de son côté, fortement professionnalisée. Tant que l’auteur de virus était un égomaniaque radical cherchant la gloire derrière un Bosach ou un Whales, les chasseurs de failles appartenaient à une caste élitiste aussi fermée que désintéressée, travaillant pour la gloire et pour des prunes . Mais, depuis une petite dizaine d’années, une faille, ça se vend aux enchères, çà s’intègre dans des « kits de fabrication de malwares », tant et si bien que la fourniture en bugs frais est devenue la principale source d’énergie de tout le système économique de la mafia cybérienne ainsi que des services de police, de renseignement et des techno-armées du monde entier. Si l’on paye du côté obscur ou gris-muraille de la force, pourquoi les « white hats » ne seraient-ils pas également rétribués ?
Cet argument, certains éditeurs l’ont compris. A commencer par le ZDI, qui non seulement rétribue les chercheurs, mais en outre leur sert de paravent juridique en cas de retour de flamme de l’éditeur faillible (car certains peuvent se montrer très hargneux). Puis sont arrivés les Mozilla Foundation avec une prime de 3000 $ par « gros » bug, Google, avec une prime de 1337 $ portée récemment à 3137,70 $. D’autres sont plus discrets, mais sont bien présents si l’on en juge par le nombre de communications rédigées, par des indépendants « on behalf of the Check Point Vulnerability Discovery Team ».
Question d’argent également chez les éditeurs. Car colmater une brèche, cela n’a rien de gratuit. Il y a le prix du développement du patch, le coût de mise en place des mesures et des politiques futures pour que tout cela ne se reproduise pas (le SDL chez Microsoft ou la « sandbox » d’Adobe, par exemple), le coût de gestion de l’infrastructure d’un Response Team, celui aussi des outils de déploiement, des plateformes de test de régression, sans oublier le prix de l’impact sur l’image de marque… chez les éditeurs, la sécurité n’est pas un « centre de profit », c’est un « département de limitation des pertes ».
Question d’argent enfin, à propos de l’évolution de la mode « prime au trou » dans un proche avenir. Beaucoup s’interrogent « Quand donc Microsoft publiera-t-il un barème de ses propres « bug’s bounty» »? Que le numéro 1 du logiciel suive l’attitude de Google ou de Mozilla, et une bonne partie de la profession suivra. Adobe et Sun (ou IBM) notamment, suivi par Cisco, Apple et autres têtes d’affiche dont les noms font les gros titres des communications Defcon, Hitb, CCC etc. Car tôt ou tard, Steve Ballmer sera contraint de rétribuer les chasseurs de bugs. On ne peut indéfiniment, critiquer, menacer, réglementer et imposer sa loi sur toute une profession sans participer à l’effort général de recherche prodigué par les « indépendants ». Dans le cas contraire, le risque serait de voir cette richesse passer, tant par dépit que par réalisme financier, entre d’autres mains, peut-être moins scrupuleuses. Le temps n’est plus où la découverte d’une faille était affaire de geek. C’est aujourd’hui un véritable marché, un business qui intéresse non seulement les truands de tous bords et des barbouzes de tous poils, mais également les concurrents qui, peu à peu, utilisent la divulgation comme une arme marketing. Le précédent « bug Ormandy » expédié tel un direct du gauche par Google dans le foie de Microsoft, ou le sympathique uppercut de Comodo dans l’estomac de Verisign le prouvent : on s’envoie désormais des gentillesses par faille interposée. Au prix de la page de réclame sur le Washington Post, un trou profond et bien faisandé remplace une bonne campagne de publicité comparative.
Se développe en outre un business de l’exploit à destination des professionnels de la sécurité. Le Français Vupen, par exemple, qui annonçait il y a quelques jours la découverte de la première faille Office 2010 « réservée aux souscripteurs du service ». En vertu de quel principe un Microsoft –ou tout autre éditeur- bénéficierait-il gratuitement du travail d’une telle entreprise, sous prétexte que le « trou » lui appartient ? Cela poserait d’ailleurs un problème moral à ce vendeur d’exploits. Admettons –pure spéculation de notre part- qu’un Vupen ou consort vende très cher à une DCRI, Direction Centrale du Renseignement Intérieur, quelconque un moyen de surveiller une horde de cyberpédophiles pratiquant l’espionnage industriel et la publication d’opuscules sur l’art de fabriquer des bombes, par exemple. Quelle serait l’attitude de ce client s’il apprenait que, 12 heures après l’achat de cette faille, ces mêmes poseurs de bombe apprenaient sur le Technet l’existence d’un e xploit « in the wild » sur Office, le tout accompagné des mesures de contournement idoines ? Car il semblerait que truands comme hommes du monde lisent indifféremment les alertes des éditeurs.
Bug business is big business. Un business que l’on a trop souvent masqué derrière une imagerie d’Epinal simpliste : des « gourous sécu » désincarnés perdus dans leurs recherches et incapables de comprendre la dure réalité du monde des affaires. Des « méchants » attendant patiemment que tombent du « full disclosure » les recettes d’infection. Des éditeurs luttant pour la sécurité de leurs clients terrorisés (car l’on parle de terrorisme pour qualifier certaines publications). Des hackers-fous incapables de comprendre que l’informatique est avant tout un outil de travail. Des « gentils chercheurs » se battant pour que la vérité triomphe, sortant, belle et nue d’un monceau de bugs et d’un trou sans fond. Non, le business de la faille, quel que soit le bord depuis lequel il est considéré –éditeur, chercheur, client, policier, cybertruand- est un véritable business. Il doit, comme tel, se doter d’un cadre normatif indépendant de toutes les parties en présence, et accepter qu’aucune des parties ne soit lésée et considérée comme quantité négligeable ou inféodée.