D'ailleurs, Lemos non plus n'hésite pas à titrer "Patches pose significant risk, researchers say". D'ici à conclure qu'il faudrait arrêter de distribuer des patches de sécurité, il n'y a qu'un pas que d'aucuns n'hésiteront pas à franchir, n'en doutons pas... En fait, je ne sais pas ce qui me dérange le plus dans cette histoire. Je ne sais pas si c'est l'alarmisme qui accompagne la sortie de ces résultats, ou si c'est l'accueil naïf, presque effaré, d'un lectorat apparemment tombé de la dernière pluie.

Parce que d'un point de vue purement technique, il faut bien avouer que ce travail ne manque pas d'intérêt. Les résultats annoncés sont prometteurs, même si on voit bien qu'il y a encore du boulot, pour autant que ce soit possible, pour produire de vrais exploits qui fonctionnent dans la vraie vie. Qui font autre chose que planter la machine, s'entend. Si on regarde en effet les exploits obtenus sur les exemples fournis[1], l'exploitation d'overflows fini systématiquement en crash, et non en exécution de commandes. Ce n'est donc pas top, mais quand même bigrement bien.

Le discours autour du papier, par contre... D'abord, on a ceux qui découvrent l'existence de l'analyse différentielle de binaires. Qui ne savaient pas que depuis fort longtemps des gens s'amusent à évaluer les différences entre un binaire vulnérable et sa version patchée pour d'une part identifier les détails techniques de la vulnérabilité corrigée et d'autre part produire l'exploit associé. Ce n'est pas comme si des outils avaient été développés spécifiquement dans ce but. Ce n'est pas non plus comme si des sociétés en avait fait une partie de leur fond de commerce. Depuis des années...

Non, l'analyse des patches n'est pas quelque chose de nouveau, et l'automatisation de ce travail autrefois manuel et fastidieux est un processus qui a commencé il y a déjà quelques temps. Pour autant, ce n'est que maintenant que la problématique de la distribution des patches fait surface. Les patches, universellement distribués, seraient trop simple à analyser nous dit-on :

One immediate consequence we suggest is that the current
patch distribution schemes are insecure, and should be
redesigned to more fully defend against automatic patch-
based exploit generation.

Rien de moins. Et comment cela va-t-il impacter le temps de production d'un patch efficace englobant ce genre de considération ? No se.

Et puis on a les alarmistes. Mais enfin ! Que fait la police ?! Comment a-t-on pu laisser une telle situation en arriver là ?! Mon dieu ! On va tous y rester. C'est oublier un peu vite ce qu'on demande quand on parle de productrion de patches. On veut des patches efficaces, testés, validés et mis à disposition à grande échelle, très rapidement. Et ensuite, il faut que les utilisateurs les récupèrent et les appliquent. Déjà, la première partie est difficile à gérer. Les éditeurs engloutissent des sommes farmineuses dans ce type de process avec de bons résultats, mais aussi, malheureusement, des échecs retentissants. Quant à la seconde, les utilisateurs, ils représentent quant à eux le maillon le plus faible. Pour pleins de raisons aussi bonnes les unes que les autres, certains estiment qu'il reste encore 20% de la population à patcher après les premières 24 heures de disponiblités. Ce qui implique effectivement qu'un exploit produit dans un laps de temps court, moins d'une heure par exemple, est capable d'impacter un nombre significatif de cibles pendant cette phase critique de diffusion. C'est un fait. Pour autant, est-ce vraiment la méthode de distribution qui est en faute ?

Je m'explique. Reprenons les hypothèses du problème. Lorsqu'un éditeur publie un patch de sécurité, il doit être distribué le plus vite possible à tous les utilisateurs de sa plate-forme. C'est le minimum vital me semble-t-il. On peut discuter des méthodes, mais globalement, un utilisateur possédant une licence valide finira par avoir son patch. Il est évident que la personne cherchant à analyser le-dit patch sera de cette population. Donc déjà, l'idée saugrenue qui ne manquera pas d'être proposée de limiter la diffusion du patch d'abord à des entités de confiance, puis au grand public, ne tient pas. D'abord parce qu'encore une fois la personne analysant le patch peut l'obtenir via une entité de confiance, comprendre quelqu'un qui paie un service de release anticipée, ensuite, et surtout, parce que l'impact maximal est atteint sur le grand public.

Mais supposons que quelqu'un parvienne à produire un système de distribution de patch qui empêche l'analyse des patches. Comme la production de patches obfusqués par exemple. Soit. Vous recevez votre patch, vous l'exécutez et il s'applique. Le tout sans que vous ayez pu l'analyser. Bingo ! But, wait a minute... A-t-on gagné pour autant ?... Ben non en fait. On n'a même rien gagné du tout. Pourquoi ? Parce que le petit détail qu'ils oublient de mentionner dans tous ces commentaires bien sentis, c'est que l'analyse ne porte pas sur le patch[2] mais sur sur les changements qu'il induit quand on l'applique en étudiant les binaires qu'il modifie. Par différence donc entre ce qu'ils étaient avant le patch et ce qu'ils sont maintenant, après le patch. Vous pourrez donc travailler tant que vous voulez sur la distribution et l'obfuscation du patch, vous ne résoudrez rien au problème puisque ce dont le méchant développeur d'exploits a besoin pour commencer à bosser, c'est juste l'appliquer... Ce qui veut dire que ce n'est pas seulement les patches qu'il faut rendre difficiles à analyser, mais l'intégralité du système, du noyau jusqu'aux plugins du navigateur. Bon courage, surtout pour les logiciels libres...


Ceci étant, comme je le disais au début, ce genre de pratique n'est pas nouvelle et l'accélération du cycle de production des exploits est une tendance qui ne l'est pas plus. On se plaignait déjà en 2003 des quelques heures qu'il avait fallu pour qu'un exploit pour MS03-026 soit publié, et ça ne s'est pas arrangé depuis, loin de là, sans même parler des 0days, dont il n'est pas question ici. Nul besoin d'être le rejeton improbable d'Albert Einstein et de Madame Soleil pour comprendre que ce délai n'allait faire que se réduire dans le temps pour n'atteindre bientôt qu'une peau de chagrin, et que le patch management allait encore avoir quelques challenges à surmonter...

Ça doit être pour ça que des gens développent des techniques compliquées pour rendre l'exploitation des failles plus difficile et surtout moins universelle. Quels visionnaires !...

Notes

[1] Cf. 4, Evaluation.

[2] Même si ça serait une voie intéressante à explorer.