Le déploiement des patches est un problème classique sur les systèmes de production. Selon le contexte, les priorités ne seront pas les mêmes : certains voudront patcher les failles les plus critiques en premier, d'autres préféreront préserver leur disponibilité en se jettant sur les patches qui ne nécessitent pas de reboot, quelques uns ne patcheront pas pour ne pas froisser des applicatifs métier chatouilleux. Sans compter ceux qui voudront commencer par celles présentant le plus grosse risque d'exploitation, même si ce dernier critère est quelque peu subjectif, donc parfois mal apprécié. Mais il faut bien commencer quelque part, me répondra-t-on. Sans parler des critères spécifiques à l'environnement. Etc...

Autant d'approches qui ne manquent pas de donner presque toutes les combinaisons de déploiement possibles et imaginables. L'exercice, combiné aux tests de validation, peut déjà se montrer lourd sur une dizaine de correctifs. Autant dire que sur une trentaine, ça commence vite à ressembler au passage de la Bérézina, en particulier quand Murphy s'en mêle ou quand vous devez croiser ça avec la livraison d'un autre éditeur. En fait, je pense qu'il arrive probablement un moment où il est probablement plus efficace de ne pas se poser la moindre question et croiser les doigts ;)

L'autre point, c'est que plus on a de vulnérabilités annoncées, plus on a de scénarios d'attaque potentiellement utilisables tant que tout n'est pas réglé. Ici, comme je le disais précédemment, parmi les seules failles jugées hautement exploitables par Microsoft, on trouvera huit exécutions distantes de code et sept élévations de privilèges. Soit un nombre conséquent de possibilités de mat en deux coups, à commencer par la fameuse faille LNK qui fait les titres depuis la semaine dernière. Ce qui ne manquera pas non plus d'influer sur l'établissement des priorités !


Ceux qui aiment les timelines record, les chiffres à slideware et autres anecdotes à sortir entre deux verres ne manqueront pas, comme Kostya, de s'intéresser à la dernière faille du bulletin MS10-048. Il trouverait son origine dans un bug remonté il y a... trois ans et demi... mais jamais pris en compte...