Fin juillet, Microsoft publiait, hors cycle normal, deux correctifs critiques, l'un - MS09-034 - corrigeant une vulnérabilité dans Internet Explorer, l'autre - MS09-035 - un problème dans l'environnement de développement Microsoft Visual Studio. La lecture des bulletins associés nous apprend que ces deux correctifs sont en fait liés: plusieurs erreurs de conception dans certains des modèles de développement C++ ATL (Active Library Template) rendent tous les composants ActiveX s'appuyant sur ces modèles vulnérables. Parmi ces composants, le contrôle ActiveX Video 'msvidctl.dll' annoncé vulnérable dans le bulletin MS09-32 diffusé il y a moins de trois semaines.
Dans ce bulletin, Microsoft recommandait de réduire l’exposition d’un système en interdisant l'exécution de ce composant en environnement Internet Explorer. Il suffisait pour cela de positionner un drapeau, dit 'KillBit', conçu à cet usage dans la base de registre. Puis, confronté à l'annonce d'une possibilité de court-circuiter ce mécanisme de protection (BlackHat USA 2009), et donc de voir un composant banni être réactivé par un tiers, Microsoft a décidé de prendre 'le taureau par les cornes' et de publier une version immune de cet ActiveX (MS09-034). En parallèle, les modèles ATL touchés ont été mis à jour (MS09-035). C’est à notre connaissance la première fois que ces modèles sont officiellement mis à jour en dehors d’une évolution de l’environnement de développement.
Une excellente initiative qui pose cependant un véritable problème de fond:
- Que des vulnérabilités soient mises en évidence dans le code d’un composant ActiveX, ou d’une bibliothèque dynamique, et il suffira d’en diffuser une nouvelle version corrigée pour qu’à la prochaine exécution de l’application, la faille soit refermée.
- Que ces vulnérabilités touchent une bibliothèque statique, et donc intégrée à l’application lors de la production (phase d’édition de lien), et il sera nécessaire non seulement de diffuser la nouvelle version de cette bibliothèque mais aussi une nouvelle version de toutes les applications l’ayant intégrée. Une opération déjà plus conséquente imposant à chaque éditeur de mettre à jour son environnement de développement et de régénérer ses applications, du moins celles utilisant les services de la bibliothèque mise en cause. La phase d’édition de lien est, fort heureusement, peu couteuse en ressources.
- Qu’une vulnérabilité touche maintenant un modèle générique de classe – c’est le cas des modèles ATL – et il sera nécessaire de recompiler l’intégralité des applications s’appuyant sur ces modèles, une opération conséquente.
Ouvrons une rapide parenthèse pour rappeler que ces modèles génériques – ou templates – permettent de définir un objet, ses propriétés et les méthodes permettant de le manipuler en faisant abstraction de ce que sera l’objet réellement utilisé par le développeur. Ainsi, et à titre d’exemple, un modèle peut permettre de définir un ensemble de ‘choses’, et les opérations associées (dénombrement, addition, soustraction, énumération…), sans jamais avoir à préciser ce que sont ces ‘choses’. C’est au moment de l’utilisation du template que le développeur précisera leur nature: nombres entiers, chaînes de caractères, ensemble d’objets… On imagine sans peine l’intérêt pratique d’une telle abstraction pour accélérer les développements en évitant de réinventer la poudre.
Cette approche suppose toutefois que ces modèles génériques, véritables fondations sur lesquelles viendront s’appuyer les développements, soient fiables et exempts de tout problème de sécurité. A une époque où n’importe quel bogue, ou presque, peut se transformer en faille de sécurité exploitable, les modèles génériques existants sont en passe de devenir de véritables pièges. Ajoutons à cela l’existence de multiples bibliothèques, et pour une même bibliothèque générique, d’autant de versions qu’il peut exister de versions de l’environnement de développement et l’on comprendra aisément le casse-tête auquel est confronté un développeur responsable.
Ainsi, et à titre d’exemple, au moins cinq versions de la librairie ATL (co)existent: ATL 2.0 et 2.1 livrées avec Visual C++ V5.0, ATL 3.0 livrée avec Visual C++ V6.0, ATL 7.0 et 7.1 introduite avec Visual C++ V6.0 et livrées avec Visual C++ .NET avec, dans certains cas, des changements conséquents allant bien au-delà d’une simple évolution fonctionnelle.
Le développeur, et l’éditeur avec lui, est alors confronté à un dilemme cornélien lorsqu’il s’agit de maintenir une application parfaitement fonctionnelle et rendant les services attendus mais développée avec un environnement commençant à dater et pour lequel les composants fondamentaux – dont les librairies ATL mais aussi WTL (la version modèle générique de la librairie de classe MFC) – ne sont plus supportés.
Microsoft a ici la part belle, en n’ayant qu’à diffuser une nouvelle version de la dernière édition de l’ATL pour se dédouaner de tout problème à venir, et en laissant aux utilisateurs de ses environnements de développement le choix de ne rien faire, ou bien de rentrer dans un cycle complexe de mise à jour des applications, et des composants associés. Mais il ne peut y avoir d’autres solutions sauf à imposer la certification de tous ces composants essentiels au développement que sont les modèles génériques de développement et les bibliothèques de classe fondamentales.
En encore, comme le dit le célèbre dicton "chassez un bogue et il reviendra au galop".
Aucun commentaire:
Enregistrer un commentaire