Une question que se pose l’Expert Français de Miami, Kostya Kortchinsky, à propos du très fameux et très récent « indice de probabilité d’exploitation » que Microsoft fournit désormais à l’occasion de chaque Patch Tuesday. « C’est une bonne idée » estime en substance l’auteur, « car elle donne au responsable sécurité un indice tangible du degré d’urgence qui caractérise le déploiement et l’application de telle ou telle rustine ». Reste que ce thermomètre de dangerosité n’est pas très fiable. Non pas, précise Kortchinsky, parce que certaines failles sont « minimisées », bien au contraire. Et de se lancer dans l’analyse de faisabilité d’un exploit portant sur une faille étiquetée « critique » dans le tout dernier bulletin Microsoft, indice d’exploitation 1 –le plus élevée sur l’échelle de Richter du Poc-. Notre chercheur s’escrime sur le code, déploie les trésors de sagacité que l’on lui connaît… en vain. Le lendemain, ledit bulletin voyait sa cote d’exploitation tomber au niveau 3, accompagné de la mention « remote code execution exploit is very unlikely », correction faite après les insistantes questions de iDefense. Des heures de travail en pure perte. La vie de forgeron du pentesting est un sacerdoce parfois bien éprouvant.
Une aventure qui remet en question la fiabilité des avis du MSRC ? Un simple « trouillomètre » dont les mesures sont liées à l’émotivité du moment ? Où, plus simplement, une erreur ponctuelle qui ne devrait pas remettre en cause le sérieux du travail effectué par les membres du MSRC. L’immense majorité des non-techniciens qui ne peuvent apprécier à leur juste mesure la subtilité et les interprétations de ces querelles d’experts, aura retenu une seule chose : Microsoft a peut-être poussé ses clients à appliquer un peu trop vite un patch qu’ils auraient éventuellement pu retarder le temps d’un test de régression. Pas de quoi fouetter un compilateur.
Microsoft se retrouve donc dans une situation à nouveau difficile à tenir. Longtemps, ses alertes de sécurité ont été systématiquement minimisées, occultées parfois. Les bugs de Windows étaient aussi officiellement inexistants que les failles exploitables dans le monde Apple. Un «négationnisme du trou » qui devait peu à peu disparaître, sous la pression des membres actifs de la liste de diffusion Full Disclosure : Liu Die Yu, http-equiv, Thor Larholm, Paul (de Greyhat) et tant d’autres. Il faudra plus de 8 ans pour retrouver une certaine confiance de la part du public, à grand renfort de blogs, de bulletins formatés, de rendez-vous fixes les seconds mardis de chaque mois, de promesses de « remise à plat » des noyaux, de politiques de développement à la sauce Software Development Lifecycle, de TPM et de trustworthy computing.
En souhaitant faire preuve d’encore plus de transparence, grâce à ce fameux indice d’exploitation, les équipes sécurité de Microsoft s’exposent une fois de plus aux critiques en cas d’erreur (humaine) de jugement. Critiques d’autant plus justifiées que, si les fausses alertes se répètent trop souvent, ces annonces pourraient provoquer un effet inverse à celui escompté. A force d’entendre crier « au loup », les vigilances s’émoussent. D’autant plus que les vigilances en question sont déjà au plus bas en temps normal. La récente affaire « conficker-downadup » a prouvé qu’au moins 40 % des grands comptes français lisaient lesdites alertes –ou respectaient lesdits avis d’urgence- d’un postérieur distrait, et ce, quelque soit le ton employé par le Microsoft Response Team.
La coupe serait pleine si, par malchance, l’un de ces indices d’exploitation « surévalué » pousse les usagers à déployer une rustine dans l’urgence et que ladite rustine provoque une régression générale. Bien que de plus en plus rare, ce genre de désagrément est déjà arrivé par le passé. Le spectre du « service pack qui tue » ou l’ombre du « correctif qui freeze » demeure encore très présent dans l’inconscient collectif des homo-informaticus.