Cette protection vise à interdire la modification des structures de l'espace noyau par des programmes ou pilotes autres que ceux fournis par l'éditeur. Une application tierce partie ne pourra donc plus jouer avec les SDT[1], IDT[2] et autres GDT[3], ou encore vadrouiller a volo dans le saint des saints du système. Alors qu'est-ce qui fait monter McAfee ou Symantec au créneau dans cette histoire ? Simplement le fait que Microsoft les prive ainsi d'un accès privilégié au système qu'ils jugent indispensable à la bonne réalisation de leurs tâches. Loin de contester qu'un programme chargé de surveiller d'autres programmes ait effectivement besoin d'un niveau de privilège plus élevé, le fait qu'il faille aller au cœur de l'OS pour cela reste largement contesté. D'ailleurs, tous les éditeurs ne semblent pas être de cet avis, comme par exemple Sophos qui affirme pouvoir se passer de ce niveau d'intrusion dans le système, donnant un peu plus de poids aux réponses de Microsoft sur la question.

Et si le débat a fini par rapidement quitter le domaine de la technique, c'est que les gens ont rapidement tendance à tout mélanger, comme dans cette brève par exemple. Qu'est-ce qu'on y lit ? Que PatchGuard va empêcher des outils de sécurité de fonctionner comme ils le font actuellement. Effectivement, ce sera le cas. On y découvre également que la protection de Vista serait illusoire, preuve en serait BluePill, la backdoor de Johanna Rutkowska présentée en juillet à SyScan. Et c'est bien mal comprendre les choses que d'avancer cette publication comme justification d'un tel discours.

D'abord parce que BluePill désigne un programme capable d'exploiter les fonctionnalitées de virtualisation des derniers processeurs AMD sous Vista. Et comme le précise l'auteur, le concept n'est ni limité à AMD, ni à Vista. On est donc à côté de la plaque. Mais on peut cependant se référer à la première partie du talk qui présente une méthode pour parvenir à exécuter du code en Ring0, niveau de privilège nécessaire à BluePill pour fonctionner. Il s'agit, par surcharge de la mémoire vive, de forcer le swapping d'un driver et d'en altérer le code par un accès direct au disque ; la réactivation du driver permettant alors l'exécution de code malicieux. Sauf que si on lit la description de PatchGuard, on s'aperçoit qu'il s'applique aussi aux drivers, et donc que cette technique ne devrait pas permettre l'accès au cœur du noyau. D'ailleurs, si c'était le cas, il aurait suffit à tous ces éditeurs bougons d'écrire un pilote spécifique pour retrouver le niveau de privilège souhaité. Or ce n'est pas le cas.

La polémique s'est donc aujourd'hui recentrée sur la position dominante de Microsoft, en ce que la mise en place de ce type de mesure porte atteinte à la concurrence en matière de sécurité. Et effectivement, on peut déplorer qu'une approche aussi radicale limite l'utilisateur dans ses choix quant à l'implémentation de sa sécurité. Mais d'un autre côté, devant l'inefficacité chronique de tous ces outils à prévenir efficacement la véritable avalanche virale qui sévit sur le net depuis ces trois dernières années, il est tout de même difficile de cracher sur une protection qu'on peut rapprocher de pas mal de projets de durcissement de systèmes d'exploitation libres, Linux en particulier, dont personne ne conteste la pertinence. S'ils sont plus souple et configurables dans leur implémentation, le but n'en reste pas mois le même : protéger le noyau coûte que coûte. S'agirait-il donc surtout d'un problème de mise en œuvre ? Probablement.

Alors ? On a aujourd'hui des outils qui, bien que jugés indispensables, ont montré leurs limites depuis longtemps. Des antivirus dépassés par les nouvelles souches qui sortent tous les jours : un simple coup de packer maison, voire un bête XOR, et le tour est joué. Des firewalls personnels qu'on contourne à grand coup d'injection de threads et de patch en mémoire. Mais que font les éditeurs pour répondre à tout ça ? La même chose : on patche les structures de processus, on injecte des threads, on redirige vers des routines de vérification, etc. On est finalement sur un terrain où les méchants et les gentils se tirent la bourre avec les mêmes outils. Or comme chacun le sait, quant on joue en premier, il est toujours plus facile de surprendre l'autre qui passe son temps à tenter de vous rattraper.

Finalement, derrière cette polémique se cache une question plus fondamentale : est-ce que nous sommes capable de reprendre l'initiative face à l'attaquant ? Et si oui, sommes nous prêts à en accepter les conséquences ? Nous savons pertinemment que la course à l'armement est vouée à l'échec. Il faut changer le fusil d'épaule et considérer d'autres techniques de protection, fussent-elles radicales. Combien de failles ont-elles été trainées par soucis de compatibilité ? WMF, ça ne vous rappelle rien ? C'est pour cela que j'ai plutôt tendance à pencher du côté de Microsoft sur ce coup là, et de ne pas pleurer sur le sort de certains d'éditeurs qui n'ont que trop tendance à nous vendent de la poudre. Ce sera peut-être une bonne occasion de laisser Darwin faire un peu de ménage dans tout ça.

Notes

[1] Service Descriptor Table.

[2] Interrupt Descriptor Table.

[3] Global Descriptor Table.