Search Results

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.

MS10-42 et MS10-45 –la faille Ormandy et un bug touchant Outlook- sont, clament la plupart des spécialistes, à « patcher immédiatement ». Le très petit défilé de rustines du dernier 14 juillet compte également un trou ActiveX et un autre dans Cdd.dll qui avait également fait l’objet d’une divulgation publique en… mai dernier. Selon les plateformes, le niveau de probabilité d’exploitation et de criticité a littéralement vidé les cartouches rouges des imprimantes du MSRC ainsi que celles du Sans.

Ce jour de bug est révolutionnaire à plus d’un titre, puisqu’il sonne également le glas du support de XP SP2. Le passage au SP3 est vivement conseillé. Un rapide sondage effectué par l’équipe de F-Secure révèle que près de 10 à 11 % des entreprises utilisent encore cette version du noyau Microsoft. En mai dernier, toujours selon les statistiques F-Secure, cette proportion atteignait 44%.

En attendant le prochain « patch Tuesday » et ses quatre bugs, dont le bouchon Ormandy, les administrateurs désœuvrés (s’il en existe) peuvent s’occuper en colmatant une vulnérabilité affectant les commutateurs « Industrial Ethernet 3000 » (IE 3000). Il s’agit en fait d’un défaut touchant le protocole snmp, et plus exactement deux « communautés » ayant pour nom « public » et « private » qui sont codées en dur, et par conséquent « permanentes ». Ce défaut n’affecte que les IOS 12.2(52)SE et 12.2(52)SE1. Une mesure de contournement est proposée, consistant à désactiver lesdites communautés à chaque démarrage de l’appareil, opération pouvant être automatisée via une politique de sécurité.

Les administrateurs de base de données, en revanche, se préparent quelques nuits blanches en raison de la préannonce du prochain lot Oracle : 59 failles, dont 21 touchant les produits Solaris et 13 bouchons pour la base Oracle. Quelques rares détails sont fournis dans le bulletin préparatoire de cette semaine.

L’été est une période critique dans le landernau du déploiement de rustines. Non pas dans les grandes entreprises –car des équipes de spécialistes veillent en permanence sur la santé des machines tout au long de l’année*- mais surtout au sein des petites structures pour qui le départ en vacances de « l’homme sécurité » peut parfois créer quelques angoisses les premiers mercredis de chaque mois de juillet et d’août.

Ce mois-ci, le MSRC (le vrai, pas l’autre nous promet le colmatage de trois défauts qualifiés de critiques : deux dans Office, un dans Windows. Un quatrième défaut non quantifié fera partie du lot. A noter également que l’équipe sécurité promet la fermeture du bulletin d’alerte 2219475, celui du célèbre débarquement d’Ormandy.

*NdlC Note de la Correctrice :… probablement dans le but de garder les trous au frais… remember Conficker !

Le blog du MSRC titre « Mise en ligne du bulletin 2219475». Cette reconnaissance officielle de la faille « online help » de Travis Ormandy déclenche également une réaction pavlovienne chez plusieurs spécialistes de l’analyse sécurité. Et notamment Secureworks, qui explique en termes simples l’importance technique de ce ZDE, et le Sans, qui fournit également le numéro CVE de ce tout nouvel exploit. Pour l’heure, il n’a pas d’utilisation malicieuse connue « dans la nature ». Quand bien même cela serait qu’un tel bug serait plutôt employé dans le cadre d’une attaque ciblée, ayant donc de fortes chances de passer sous le radar des principaux honeypots.

L’on se souvient de la faille Win32hlp (https://www.cnis-mag.com/pour-pirater-appuyez-sur-f1.html) découverte il y a trois mois par Maurycy Prodeus. Celle dévoilée par le talentueux Tavis Ormandy est tout aussi savoureuse, voire même plus subtile, puisqu’elle repose sur un défaut d’interprétation du protocole hcp, le Help Center Protocol, reconnaissable grâce à l’url « hcp:// ». « Aurais-je signalé qu’il était possible de forger une réponse pour accéder au poste requêteur à distance que l’on ne m’aurait prêté aucune attention » dit en substance Ormandy à la fin de son communiqué. Communiqué qui intègre notamment une preuve de faisabilité.

Certes, cette attaque implique que l’attaquant puisse se substituer au centre d’aide et de support en ligne de Microsoft, et que la victime n’utilise pas un noyau trop récent (l’attaque n’est censée fonctionner pour l’instant que sur les plateformes XP/2003). Le risque est pourtant non nul et repose, une fois de plus, la question de la confiance que l’on doit apporter aux services en ligne des éditeurs possédant une bonne « réputation ».

Après les 25 derniers bouchons Microsoft, la semaine des diffuseurs de correctifs a pris des allures de tour de France, séquence « montée du col de la Colombière ». Le MS-Virage une fois dépassé (appelé « le reposoir », le bien nommé), le peloton a attaqué la longue montée des patchs Oracle : 47 injections de ce fameux « pot SGBD » au logo de l’éditeur. Un cocktail qui, faut-il le remarquer, intègre une belle proportion de bouchons Sun. Le même jour, les spectateurs pouvaient constater que les concurrents de l’équipe Cisco avaient encore de la ressource, et contre-attaquaient avec un problème ActiveX, immédiatement talonné par un maillot Apple, le dossard CVE-2010-1120 pour être précis, qui masquait une fonte forgée pouvant conduire à des droits d’exécution anormaux. Se sentant distancée, l’équipe Sun revient avec deux security fix qui passent presque inaperçus. Car à ce moment très précis, Adobe reprend du poil de la bête, et l’on voit alors partir comme des fusées les failles CVE-2010-0190, CVE-2010-0191, CVE-2010-0192, CVE-2010-0193, CVE-2010-0194, CVE-2010-0195, CVE-2010-0196, CVE-2010-0197, CVE-2010-0198, CVE-2010-0199, CVE-2010-0201, CVE-2010-0202, CVE-2010-0203, CVE-2010-0204, CVE-2010-1241… inutile de les compter, il y en a 15 au total. Le tout empaqueté dans un bulletin général de bonne tenue, garanti sans stéroïde anabolisant.

Autour du peloton, les équipes médicales s’affairent. Les envoyés spéciaux de la chaine M86, postés à la buvette du col nous signalent que durant la nuit, le « bug-feature PDF de Didier Stevens » est passé du stade de « proof of concept » à celui d’attaque transportant de véritables morceaux de Zeus. Par le plus grand des hasards, une autre « faille de laboratoire », découverte, elle, par Tavis Ormandy s’est également transformée en véritable « exploit in the wild » comme disent les professionnels du cyclisme (discipline proche du Development Life Cycle viral). Ce serait AVG qui serait le premier tombé sur une preuve de cette exploitation. Le Sans a immédiatement sorti la Sécotine et, en l’absence de rustine effective, a derechef publié deux mesures de contournement pendant que le Team Oracle se demandait si les spectateurs allaient pouvoir se contenter d’une promesse de rectification dans les trois mois à venir. Mais, puisant dans ses ressources, le leader de l’équipe Oracle a pu fournir un impressionnant Java 6 Update 20.

Après la superbe et pourtant antique faille VDM, voici que Tavis Ormandy dévoile un nouveau trou de sécurité affectant cette fois le composant Java Web Start de Sun/Oracle, dans sa version destinée à « tous les environnements Windows ». Devant le peu de réaction de la part d’Oracle qui estimerait que le trou de sécurité ne nécessite pas de correctif « hors calendrier » (Le rythme des rustines Oracle est trimestriel), le chercheur a décidé de publier à la fois une alerte sur la liste Full Disclosure (http://www.derkeiler.com/Mailing-Lists/Full-Disclosure/2010-04/msg00123.html) et une preuve de faisabilité sur son propre site. PoC qui exécute à distance le lancement de la calculatrice Windows.

Bien que précisant un prudent « I believe non-Windows installations are unaffected », il semblerait tout de même que Linux en pâtisse également. C’est ce qu’indique en tout cas le blog de Ruben Santamarta, qui accompagne également ses recherches d’un petit code d’exploitation. Santamarta précise toutefois « Bien que Linux contienne ce code vulnérable, je n’ai pas été capable de l’exploiter de la même manière ».

Les mauvaises langues diront qu’il y a là un certain parfum de vengeance… Tavis Ormandy, sur le « Full Disclo », signale l’existence d’une faille dans le support 16 bits de Windows NT. Un trou qui remonte à la haute époque de Windows NT 3.10 (le tout premier du nom). Pour information, Tavis Ormandy est Information Security Engineer chez Google. Vous avez dit bizarre ? Comme c’est étrange ! Sa découverte aurait fait l’objet d’une première signalisation fin juin 2009 et serait demeurée sans correction depuis… Ce qui aurait motivé la publication spontanée de ce PoC à piquer sur l’une des ressources de l’auteur. Ah, si tout le réseau Google avait utilisé Chrome et Chrome OS…

La parade est simple, explique Sylvain Sarmejeanne sur le blog du Cert Lexsi, puisqu’il s’agit de désactiver le sous-système 16 bits. Une astuce également signalée par l’inventeur de la faille et l’équipe technique de Microsoft au fil d’une alerte publiée le 20 du mois. Les noyaux 64 bits, précise l’éditeur, ne seraient pas concernés. Toujours dans ce même communiqué, l’on peut lire la description pas à pas d’une modification de la ruche supprimant les exécutions en mode 16 bits. Voilà qui risque de poser quelques problème à d’antiques applications héritées de la période « Nantucket Clipper » et autres vieilleries, qui n’ont plus de possibilité de survie que dans le cadre étroit et ralenti d’une machine virtuelle sous Hyper-V ou Virtual PC.

Le calendrier de la prochaine PacSec2009 de Tokyo, qui se déroulera les 4 et 5 novembre prochain, vient d’être arrêté en ce début de semaine. L’on y entendra notamment Tavis Ormandy et Julien Tinnes, de Google, à propos de sécurité dans la virtualisation, Karsten Nohl à propos d’un sujet toujours aussi magique et mystérieux, le hacking matériel des puces (microscope à l’appui), tandis que Charlie Miller dévoilera les secret du fuzzing SMS ciblant l’iPhone, que Rich Cannings et Alex Stamos disserterons sur la sécurité de la plateforme Android ou que Eric Filiol replongera dans les arcanes du chiffrement des documents Word et Excel.

La conférence CanSecWest 2010, quand à elle, est en cours de constitution, et les organisateurs lancent leur premier appel à communications. Cet événement se déroulera du 22 au 26 mars prochain à Vancouver, dans les salons du Sheraton Wall Centre.